From issues at jboss.org  Wed Feb  1 02:22:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 1 Feb 2017 02:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6195) Tests fail on IBM JDK with
 security manager
In-Reply-To: <JIRA.12603702.1455277250000@Atlassian.JIRA>
References: <JIRA.12603702.1455277250000@Atlassian.JIRA>
	<JIRA.12603702.1455277250000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603702.1455277250000.38088.1485933720471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky resolved WFLY-6195.
---------------------------------
    Resolution: Done


Fixed by Elytron 1.1.0.Beta4.

> Tests fail on IBM JDK with security manager
> -------------------------------------------
>
>                 Key: WFLY-6195
>                 URL: https://issues.jboss.org/browse/WFLY-6195
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Hynek ?v?bek
>            Assignee: Hynek ?v?bek
>
> *org.jboss.as.test.integration.batch.chunk.ChunkPartitionTestCase#chunks*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#definedInMemoryTest*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#namedInMemoryTest*
> *org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase#namedJdbcTest*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.chunk.ChunkPartitionTestCase#chunks}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase}}
> Fails with:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component BatchExecutionService for method public javax.batch.runtime.JobExecution org.jboss.as.test.integration.batch.common.BatchExecutionService.start(java.lang.String,java.util.Properties): javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService$$$view3.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	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:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.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:507)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> &amp#27;[0m&amp#27;[31m08:08:10,462 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /batch-defined-in-memory//start: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService$$$view3.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	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:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.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:507)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-defined-in-memory.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> {code}
> *org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase#testClientLoginModule*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase#testSecurityContextAssociation*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase#testClientLoginModule*
> *org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase#testSecurityContextAssociation*
> {./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase{}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.ejb.container.interceptor.security.api.SwitchIdentityTestCase}}
>  
> Fail with:
> {code}
> javax.ejb.EJBException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "org.jboss.as.ejb3.remote-tx-timeout" "read")" in code source "(vfs:/content/ejb-security-interceptors-test.jar <no signer certificates>)" of "null")
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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:507)
> 	at org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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 ...asynchronous invocation...(Unknown Source)
> 	at java.lang.Thread.getStackTrace(Thread.java:1117)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ClientSecurityInterceptor.handleInvocationResult(ClientSecurityInterceptor.java:62)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy73.allRoles(Unknown Source)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testMethodAccess(SwitchIdentityTestCase.java:279)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.callUsingSecurityContextAssociation(SwitchIdentityTestCase.java:251)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.SwitchIdentityTestCase.testSecurityContextAssociation(SwitchIdentityTestCase.java:174)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "org.jboss.as.ejb3.remote-tx-timeout" "read")" in code source "(vfs:/content/ejb-security-interceptors-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Integer.getInteger(Integer.java:1113)
> 	at java.lang.Integer.getInteger(Integer.java:1069)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.createOrResumeXidTransaction(EJBRemoteTransactionPropagatingInterceptor.java:117)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:71)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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:507)
> 	at org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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 ...asynchronous invocation...(Unknown Source)
> 	at java.lang.Thread.getStackTrace(Thread.java:1117)
> 	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> 	at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ClientSecurityInterceptor.handleInvocationResult(ClientSecurityInterceptor.java:62)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy202.allRoles(Unknown Source)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.BridgeBean.allRoles(BridgeBean.java:55)
> 	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:507)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:138)
> 	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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.test.integration.ejb.container.interceptor.security.ServerSecurityInterceptor.aroundInvoke(ServerSecurityInterceptor.java:108)
> 	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:507)
> 	at org.jboss.as.ejb3.component.ContainerInterceptorMethodInterceptorFactory$ContainerInterceptorMethodInterceptor.processInvocation(ContainerInterceptorMethodInterceptorFactory.java:91)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:57)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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:322)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:254)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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}
> *org.jboss.as.test.integration.batch.flow.FlowTestCase#flow*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.batch.flow.FlowTestCase#flow}}
> Fails with:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component BatchExecutionService for method public javax.batch.runtime.JobExecution org.jboss.as.test.integration.batch.common.BatchExecutionService.start(java.lang.String,java.util.Properties): javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService$$$view6.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	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:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.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:507)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> &amp#27;[0m&amp#27;[31m08:08:29,221 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /batch-flow//start: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	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.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 java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:75)
> 	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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService$$$view6.start(Unknown Source)
> 	at org.jboss.as.test.integration.batch.common.StartBatchServlet.doGet(StartBatchServlet.java:65)
> 	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:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
> 	at java.security.AccessController.doPrivileged(AccessController.java:650)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	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.xml.stream.FactoryConfigurationError: Provider __redirected.__XMLInputFactory could not be instantiated: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at javax.xml.stream.XMLInputFactory.newFactory(Unknown Source)
> 	at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
> 	at org.jberet.job.model.JobParser.parseJob(JobParser.java:48)
> 	at org.jberet.creation.ArchiveXmlLoader.loadJobXml(ArchiveXmlLoader.java:97)
> 	at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:102)
> 	at org.jboss.as.test.integration.batch.common.BatchExecutionService.start(BatchExecutionService.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:507)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 70 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "com.ctc.wstx.returnNullForDefaultNamespace" "read")" in code source "(vfs:/content/batch-flow.war/WEB-INF/classes <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
> 	at java.lang.System.getProperty(System.java:431)
> 	at java.lang.System.getProperty(System.java:415)
> 	at java.lang.Boolean.getBoolean(Boolean.java:265)
> 	at com.ctc.wstx.api.CommonConfig.<init>(CommonConfig.java:113)
> 	at com.ctc.wstx.api.ReaderConfig.<init>(ReaderConfig.java:482)
> 	at com.ctc.wstx.api.ReaderConfig.createFullDefaults(ReaderConfig.java:533)
> 	at com.ctc.wstx.stax.WstxInputFactory.<init>(WstxInputFactory.java:148)
> 	at sun.reflect.GeneratedConstructorAccessor10.newInstance(Unknown Source)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:436)
> 	at __redirected.__XMLInputFactory.<init>(__XMLInputFactory.java:111)
> 	at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> 	at java.lang.Class.newInstance(Class.java:1924)
> 	at javax.xml.stream.FactoryFinder.newInstance(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	at javax.xml.stream.FactoryFinder.find(Unknown Source)
> 	... 103 more
> {code}
> *org.jboss.as.test.integration.web.websocket.WebSocketTestCase#testWebSocket*
> {{mvn clean test -Dsecurity.manager -Dtest=org.jboss.as.test.integration.web.websocket.WebSocketTestCase#testWebSocket}}
> Fails with:
> {code}
> java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "io.undertow.websockets.BIND_ADDRESS" "read")" in code source "(vfs:/content/websocket.war/WEB-INF/classes <no signer certificates>)" of "null")
>         at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
>         at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
>         at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1307)
>         at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:489)
>         at java.lang.System.getProperty(System.java:431)
>         at java.lang.System.getProperty(System.java:415)
>         at io.undertow.websockets.client.WebSocketClient$ConnectionBuilder.connect(WebSocketClient.java:229)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:440)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServerInternal(ServerWebSocketContainer.java:434)
>         at io.undertow.websockets.jsr.ServerWebSocketContainer.connectToServer(ServerWebSocketContainer.java:194)
>         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  Wed Feb  1 02:59:00 2017
From: issues at jboss.org (Toshiya Kobayashi (JIRA))
Date: Wed, 1 Feb 2017 02:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1387) PHREAK is slower than
 ReteOO with accumulate and exists
In-Reply-To: <JIRA.12668861.1482891706000@Atlassian.JIRA>
References: <JIRA.12668861.1482891706000@Atlassian.JIRA>
	<JIRA.12668861.1482891706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668861.1482891706000.38258.1485935940446@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356017#comment-13356017 ] 

Toshiya Kobayashi commented on DROOLS-1387:
-------------------------------------------

Finally, I understand that all rules are linked in this test case and it results in the performance difference. Wrote a blog post from the investigation (https://tkobayas.wordpress.com/2017/01/17/phreak-unlinking/). Closing this JIRA. Thanks, Mario and Tibor!

> PHREAK is slower than ReteOO with accumulate and exists
> -------------------------------------------------------
>
>                 Key: DROOLS-1387
>                 URL: https://issues.jboss.org/browse/DROOLS-1387
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>              Labels: support
>         Attachments: brms-perf-comarison-02.zip, brms-perf-comarison.zip
>
>
> PHREAK is slower than ReteOO in case of:
> 1. with accumulate
> 2. with exists
> Attached test case brms-perf-comarison.zip contains 4 tests to compare the performance:
> ReteOO_Accumulate vs Phreak_Accumulate
>  -> ReteOO is 30% faster than PHREAK in average
> ReteOO_Exists vs Phreak_Exists
>  -> ReteOO is 30% faster than PHREAK in average
> You can run the test with
> {noformat}
> mvn -P BRMS640GA clean test
> {noformat}
> The example output:
> {noformat}
> Running org.mk300.brms.perf.Phreak_Accumulate
> 2016-12-27 16:51:40,280 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:42,322 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:42,519 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 0 tx/sec
> 2016-12-27 16:51:43,529 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 29,020 tx/sec
> 2016-12-27 16:51:44,533 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 159,216 tx/sec
> 2016-12-27 16:51:45,539 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 203,391 tx/sec
> 2016-12-27 16:51:46,539 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,453 tx/sec
> 2016-12-27 16:51:47,553 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 204,160 tx/sec
> 2016-12-27 16:51:48,555 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 199,914 tx/sec
> 2016-12-27 16:51:49,556 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 193,496 tx/sec
> 2016-12-27 16:51:50,557 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 200,377 tx/sec
> 2016-12-27 16:51:51,557 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,060 tx/sec
> 2016-12-27 16:51:52,522 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.394 sec - in org.mk300.brms.perf.Phreak_Accumulate
> Running org.mk300.brms.perf.Phreak_Exists
> 2016-12-27 16:51:52,860 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:54,521 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:54,716 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 0 tx/sec
> 2016-12-27 16:51:55,737 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 72,411 tx/sec
> 2016-12-27 16:51:56,737 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 257,065 tx/sec
> 2016-12-27 16:51:57,741 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 292,136 tx/sec
> 2016-12-27 16:51:58,746 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 283,862 tx/sec
> 2016-12-27 16:51:59,753 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 285,201 tx/sec
> 2016-12-27 16:52:00,753 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 290,762 tx/sec
> 2016-12-27 16:52:01,760 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 291,661 tx/sec
> 2016-12-27 16:52:02,760 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,011 tx/sec
> 2016-12-27 16:52:03,767 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,844 tx/sec
> 2016-12-27 16:52:04,719 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.004 sec - in org.mk300.brms.perf.Phreak_Exists
> Running org.mk300.brms.perf.ReteOO_Accumulate
> 2016-12-27 16:52:05,068 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:07,139 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:07,349 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 0 tx/sec
> 2016-12-27 16:52:08,368 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 50,996 tx/sec
> 2016-12-27 16:52:09,380 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 217,269 tx/sec
> 2016-12-27 16:52:10,391 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 252,807 tx/sec
> 2016-12-27 16:52:11,453 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 245,798 tx/sec
> 2016-12-27 16:52:12,457 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 225,747 tx/sec
> 2016-12-27 16:52:13,458 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 254,959 tx/sec
> 2016-12-27 16:52:14,487 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 249,093 tx/sec
> 2016-12-27 16:52:15,496 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,899 tx/sec
> 2016-12-27 16:52:16,517 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,790 tx/sec
> 2016-12-27 16:52:17,375 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.455 sec - in org.mk300.brms.perf.ReteOO_Accumulate
> Running org.mk300.brms.perf.ReteOO_Exists
> 2016-12-27 16:52:17,751 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:19,431 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:19,643 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 0 tx/sec
> 2016-12-27 16:52:20,656 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 99,934 tx/sec
> 2016-12-27 16:52:21,679 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 308,091 tx/sec
> 2016-12-27 16:52:22,700 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 331,749 tx/sec
> 2016-12-27 16:52:23,721 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,276 tx/sec
> 2016-12-27 16:52:24,721 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,285 tx/sec
> 2016-12-27 16:52:25,732 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 349,222 tx/sec
> 2016-12-27 16:52:26,746 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 339,559 tx/sec
> 2016-12-27 16:52:27,754 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,000 tx/sec
> 2016-12-27 16:52:28,756 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,937 tx/sec
> 2016-12-27 16:52:29,647 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.056 sec - in org.mk300.brms.perf.ReteOO_Exists
> {noformat}
> NOTE: These tests run in different JVMs (reuseForks = false in pom.xml) so the order of test execution doesn't affect the performance.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 03:02:00 2017
From: issues at jboss.org (Toshiya Kobayashi (JIRA))
Date: Wed, 1 Feb 2017 03:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1387) PHREAK is slower than
 ReteOO with accumulate and exists
In-Reply-To: <JIRA.12668861.1482891706000@Atlassian.JIRA>
References: <JIRA.12668861.1482891706000@Atlassian.JIRA>
	<JIRA.12668861.1482891706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668861.1482891706000.38307.1485936120955@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toshiya Kobayashi closed DROOLS-1387.
-------------------------------------
    Resolution: Rejected


> PHREAK is slower than ReteOO with accumulate and exists
> -------------------------------------------------------
>
>                 Key: DROOLS-1387
>                 URL: https://issues.jboss.org/browse/DROOLS-1387
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>              Labels: support
>         Attachments: brms-perf-comarison-02.zip, brms-perf-comarison.zip
>
>
> PHREAK is slower than ReteOO in case of:
> 1. with accumulate
> 2. with exists
> Attached test case brms-perf-comarison.zip contains 4 tests to compare the performance:
> ReteOO_Accumulate vs Phreak_Accumulate
>  -> ReteOO is 30% faster than PHREAK in average
> ReteOO_Exists vs Phreak_Exists
>  -> ReteOO is 30% faster than PHREAK in average
> You can run the test with
> {noformat}
> mvn -P BRMS640GA clean test
> {noformat}
> The example output:
> {noformat}
> Running org.mk300.brms.perf.Phreak_Accumulate
> 2016-12-27 16:51:40,280 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:42,322 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:42,519 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 0 tx/sec
> 2016-12-27 16:51:43,529 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 29,020 tx/sec
> 2016-12-27 16:51:44,533 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 159,216 tx/sec
> 2016-12-27 16:51:45,539 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 203,391 tx/sec
> 2016-12-27 16:51:46,539 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,453 tx/sec
> 2016-12-27 16:51:47,553 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 204,160 tx/sec
> 2016-12-27 16:51:48,555 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 199,914 tx/sec
> 2016-12-27 16:51:49,556 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 193,496 tx/sec
> 2016-12-27 16:51:50,557 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 200,377 tx/sec
> 2016-12-27 16:51:51,557 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Accumulate : 202,060 tx/sec
> 2016-12-27 16:51:52,522 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.394 sec - in org.mk300.brms.perf.Phreak_Accumulate
> Running org.mk300.brms.perf.Phreak_Exists
> 2016-12-27 16:51:52,860 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:51:54,521 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:51:54,716 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 0 tx/sec
> 2016-12-27 16:51:55,737 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 72,411 tx/sec
> 2016-12-27 16:51:56,737 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 257,065 tx/sec
> 2016-12-27 16:51:57,741 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 292,136 tx/sec
> 2016-12-27 16:51:58,746 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 283,862 tx/sec
> 2016-12-27 16:51:59,753 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 285,201 tx/sec
> 2016-12-27 16:52:00,753 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 290,762 tx/sec
> 2016-12-27 16:52:01,760 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 291,661 tx/sec
> 2016-12-27 16:52:02,760 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,011 tx/sec
> 2016-12-27 16:52:03,767 INFO  (pool-1-thread-1) [PerfCounter] Phreak_Exists : 296,844 tx/sec
> 2016-12-27 16:52:04,719 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.004 sec - in org.mk300.brms.perf.Phreak_Exists
> Running org.mk300.brms.perf.ReteOO_Accumulate
> 2016-12-27 16:52:05,068 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:07,139 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:07,349 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 0 tx/sec
> 2016-12-27 16:52:08,368 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 50,996 tx/sec
> 2016-12-27 16:52:09,380 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 217,269 tx/sec
> 2016-12-27 16:52:10,391 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 252,807 tx/sec
> 2016-12-27 16:52:11,453 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 245,798 tx/sec
> 2016-12-27 16:52:12,457 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 225,747 tx/sec
> 2016-12-27 16:52:13,458 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 254,959 tx/sec
> 2016-12-27 16:52:14,487 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 249,093 tx/sec
> 2016-12-27 16:52:15,496 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,899 tx/sec
> 2016-12-27 16:52:16,517 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Accumulate : 237,790 tx/sec
> 2016-12-27 16:52:17,375 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.455 sec - in org.mk300.brms.perf.ReteOO_Accumulate
> Running org.mk300.brms.perf.ReteOO_Exists
> 2016-12-27 16:52:17,751 INFO  (main) [RuleBase] ##################### RuleBase start
> 2016-12-27 16:52:19,431 INFO  (main) [KieRepositoryImpl] KieModule was added: MemoryKieModule[releaseId=org.default:artifact:1.0.0-SNAPSHOT]
> 2016-12-27 16:52:19,643 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 0 tx/sec
> 2016-12-27 16:52:20,656 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 99,934 tx/sec
> 2016-12-27 16:52:21,679 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 308,091 tx/sec
> 2016-12-27 16:52:22,700 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 331,749 tx/sec
> 2016-12-27 16:52:23,721 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,276 tx/sec
> 2016-12-27 16:52:24,721 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 351,285 tx/sec
> 2016-12-27 16:52:25,732 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 349,222 tx/sec
> 2016-12-27 16:52:26,746 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 339,559 tx/sec
> 2016-12-27 16:52:27,754 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,000 tx/sec
> 2016-12-27 16:52:28,756 INFO  (pool-1-thread-1) [PerfCounter] ReteOO_Exists : 328,937 tx/sec
> 2016-12-27 16:52:29,647 INFO  (main) [RuleBase] ##################### disposeAll end
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.056 sec - in org.mk300.brms.perf.ReteOO_Exists
> {noformat}
> NOTE: These tests run in different JVMs (reuseForks = false in pom.xml) so the order of test execution doesn't affect the performance.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 03:44:01 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 1 Feb 2017 03:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8005) There are two different error
 messages for adding duplicate record to CS with same command.
In-Reply-To: <JIRA.12674072.1485938614000@Atlassian.JIRA>
References: <JIRA.12674072.1485938614000@Atlassian.JIRA>
	<JIRA.12674072.1485938614486@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674072.1485938614000.38447.1485938641951@Atlassian.JIRA>

Hynek ?v?bek created WFLY-8005:
----------------------------------

             Summary: There are two different error messages for adding duplicate record to CS with same command.
                 Key: WFLY-8005
                 URL: https://issues.jboss.org/browse/WFLY-8005
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse


There are two different error messages for adding duplicate record to CS with 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  Wed Feb  1 03:45:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 1 Feb 2017 03:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8005) There are two different error
 messages for adding duplicate record to CS with same command.
In-Reply-To: <JIRA.12674072.1485938614000@Atlassian.JIRA>
References: <JIRA.12674072.1485938614000@Atlassian.JIRA>
	<JIRA.12674072.1485938614000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674072.1485938614000.38459.1485938700691@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned WFLY-8005:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> There are two different error messages for adding duplicate record to CS with same command.
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8005
>                 URL: https://issues.jboss.org/browse/WFLY-8005
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> There are two different error messages for adding duplicate record to CS with 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  Wed Feb  1 03:49:00 2017
From: issues at jboss.org (LakshmiNarayanan Kesavan (JIRA))
Date: Wed, 1 Feb 2017 03:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1423) KJAR changes are not
 reflected in KIE Container
In-Reply-To: <JIRA.12673995.1485883456000@Atlassian.JIRA>
References: <JIRA.12673995.1485883456000@Atlassian.JIRA>
	<JIRA.12673995.1485883456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673995.1485883456000.38464.1485938940163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356037#comment-13356037 ] 

LakshmiNarayanan Kesavan commented on DROOLS-1423:
--------------------------------------------------

Thanks. We will try to implement this and get back to you.

> KJAR changes are not reflected in KIE Container
> -----------------------------------------------
>
>                 Key: DROOLS-1423
>                 URL: https://issues.jboss.org/browse/DROOLS-1423
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.5.0.Final
>            Reporter: LakshmiNarayanan Kesavan
>            Assignee: Edson Tirelli
>
> Step 1: Create a KJAR in Maven Repo with the DRL file and deploy the same in tomcat
> Step 2: Create the container
> Step 3: Execute the rule. The rule got successfully executed
> Step 4: Dispose the container. We get the below message
> 31-Jan-2017 14:50:13.001 INFO [http-nio-8000-exec-12] org.kie.server.services.jbpm.JbpmKieServerExtension.disposeContainer No container with id test_drl_nn_01_1 found
> 31-Jan-2017 14:50:13.002 INFO [http-nio-8000-exec-12] org.kie.server.services.impl.KieServerImpl.disposeContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully stopped
> Step 5: Try executing the rule. No container available hence the rule didnt get executed.
> Step 6: Modify the rule logic and create the new KJAR
> Step 7: Create container and we get the below message.
> 31-Jan-2017 15:01:44.333 WARNING [http-nio-8000-exec-10] org.kie.server.services.jbpm.ui.JBPMUIKieServerExtension.createContainer Unable to create image reference for container test_drl_nn_01_1 due to null
> 31-Jan-2017 15:01:44.334 INFO [http-nio-8000-exec-10] org.kie.server.services.impl.KieServerImpl.createContainer Container test_drl_nn_01_1 (for release id com.ge.hc.services.rs:test_drl_nn_01:1) successfully started
> Step 8: execute the rule. 
> We observe the latest changes made to the rule logic is not reflecting in the container and only the old(OLD KJAR WITH OLD RULE LOGIC) contanier got created.
> This happens very sporadically and not always



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 03:57:00 2017
From: issues at jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 1 Feb 2017 03:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8006) Re-enable all IIOP naming
	tests
In-Reply-To: <JIRA.12674075.1485939401000@Atlassian.JIRA>
References: <JIRA.12674075.1485939401000@Atlassian.JIRA>
	<JIRA.12674075.1485939401253@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674075.1485939401000.38546.1485939420100@Atlassian.JIRA>

Carlo de Wolf created WFLY-8006:
-----------------------------------

             Summary: Re-enable all IIOP naming tests
                 Key: WFLY-8006
                 URL: https://issues.jboss.org/browse/WFLY-8006
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 04:22:01 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 1 Feb 2017 04:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8005) There are two different error
 messages for adding duplicate record to CS with same command.
In-Reply-To: <JIRA.12674072.1485938614000@Atlassian.JIRA>
References: <JIRA.12674072.1485938614000@Atlassian.JIRA>
	<JIRA.12674072.1485938614000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674072.1485938614000.38733.1485940921613@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated WFLY-8005:
-------------------------------
    Description: 
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.

  was:
There are two different error messages for adding duplicate record to CS with 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.



> There are two different error messages for adding duplicate record to CS with same command.
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8005
>                 URL: https://issues.jboss.org/browse/WFLY-8005
>             Project: WildFly
>          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  Wed Feb  1 04:22:01 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Wed, 1 Feb 2017 04:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8005) There are two different error
 messages for adding duplicate record to CS by same command.
In-Reply-To: <JIRA.12674072.1485938614000@Atlassian.JIRA>
References: <JIRA.12674072.1485938614000@Atlassian.JIRA>
	<JIRA.12674072.1485938614000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674072.1485938614000.38740.1485940921932@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated WFLY-8005:
-------------------------------
    Summary: There are two different error messages for adding duplicate record to CS by same command.  (was: There are two different error messages for adding duplicate record to CS with same command.)


> There are two different error messages for adding duplicate record to CS by same command.
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-8005
>                 URL: https://issues.jboss.org/browse/WFLY-8005
>             Project: WildFly
>          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  Wed Feb  1 04:25:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 1 Feb 2017 04:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-27) Analyze Distributed
 tracing and OpenTracing
In-Reply-To: <JIRA.12674082.1485941069000@Atlassian.JIRA>
References: <JIRA.12674082.1485941069000@Atlassian.JIRA>
	<JIRA.12674082.1485941069511@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674082.1485941069000.38754.1485941100159@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-27:
----------------------------------------

             Summary: Analyze Distributed tracing and OpenTracing
                 Key: HAWKULARQE-27
                 URL: https://issues.jboss.org/browse/HAWKULARQE-27
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user


Watch presentation and demo video:

Slides: https://docs.google.com/a/redhat.com/presentation/d/1wGow7RmOuA8nfaQV7N5Isk-6EtkWSm0XyjTctxSoZ2k/edit?usp=sharing
Video:  https://youtu.be/XIYIEBY-rAM?t=2m17s



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 04:33:01 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 1 Feb 2017 04:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1424) Variance and standard
 deviation function in Drools out of the box
In-Reply-To: <JIRA.12674085.1485941575000@Atlassian.JIRA>
References: <JIRA.12674085.1485941575000@Atlassian.JIRA>
	<JIRA.12674085.1485941575443@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674085.1485941575000.38833.1485941581749@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1424:
----------------------------------------

             Summary: 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: Mario Fusco


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 Feb  1 04:34:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 04:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941627000@Atlassian.JIRA>
References: <JIRA.12674086.1485941627000@Atlassian.JIRA>
	<JIRA.12674086.1485941627899@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941627000.38838.1485941640315@Atlassian.JIRA>

Ondrej Lukas created ELY-902:
--------------------------------

             Summary: Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
                 Key: ELY-902
                 URL: https://issues.jboss.org/browse/ELY-902
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.

We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.

Deployment fails with following exception in server log:

{code}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
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$4(ApplicationSecurityDomainDefinition.java:416)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
	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:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
	... 8 more

ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
}
{code}

It is similar issue as JBEAP-6401 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 04:35:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 04:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.38841.1485941700435@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-902:
-----------------------------
    Component/s: Realms


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as JBEAP-6401 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 04:35:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 04:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.38844.1485941700543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-902:
-----------------------------
    Description: 
In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.

We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.

Deployment fails with following exception in server log:

{code}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
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$4(ApplicationSecurityDomainDefinition.java:416)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
	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:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
	... 8 more

ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
}
{code}

It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.

  was:
In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.

We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.

Deployment fails with following exception in server log:

{code}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
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$4(ApplicationSecurityDomainDefinition.java:416)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
	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:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
	... 8 more

ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
    Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
}
{code}

It is similar issue as JBEAP-6401 - the difference is that {{direct-verification=true}} is configured in current issue.



> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 04:35:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 04:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.38851.1485941700884@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-902:
-----------------------------
    Affects Version/s: 1.1.0.Beta21


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:04:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 1 Feb 2017 06:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2254)
 InterdependentDeploymentTestCase fails with security manager
In-Reply-To: <JIRA.12674107.1485947035000@Atlassian.JIRA>
References: <JIRA.12674107.1485947035000@Atlassian.JIRA>
	<JIRA.12674107.1485947035787@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674107.1485947035000.39646.1485947041208@Atlassian.JIRA>

Jan Tymel created WFCORE-2254:
---------------------------------

             Summary: InterdependentDeploymentTestCase fails with security manager
                 Key: WFCORE-2254
                 URL: https://issues.jboss.org/browse/WFCORE-2254
             Project: WildFly Core
          Issue Type: Bug
          Components: Test Suite
            Reporter: Jan Tymel
            Assignee: Tomaz Cerar


*org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase#test*

{{cd testsuite/manualmode/}}
{{mvn test -DtestLogToFile=false -Dtest=InterdependentDeploymentTestCase -Dsecurity.manager}}

{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service ServiceActivatorDeployment.c: org.jboss.msc.service.StartException in service ServiceActivatorDeployment.c: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
	at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "interrelated-c.jar" "write")" in code source "(vfs:/content/interrelated-a.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.interrelated-a.jar" from Service Module Loader")
	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
	at java.lang.System.setProperty(System.java:792)
	at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:91)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
	... 4 more
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:05:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 1 Feb 2017 06:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2254)
 InterdependentDeploymentTestCase fails with security manager
In-Reply-To: <JIRA.12674107.1485947036000@Atlassian.JIRA>
References: <JIRA.12674107.1485947036000@Atlassian.JIRA>
	<JIRA.12674107.1485947036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674107.1485947036000.39649.1485947100194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reassigned WFCORE-2254:
---------------------------------

    Assignee:     (was: Tomaz Cerar)


> InterdependentDeploymentTestCase fails with security manager
> ------------------------------------------------------------
>
>                 Key: WFCORE-2254
>                 URL: https://issues.jboss.org/browse/WFCORE-2254
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>
> *org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase#test*
> {{cd testsuite/manualmode/}}
> {{mvn test -DtestLogToFile=false -Dtest=InterdependentDeploymentTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service ServiceActivatorDeployment.c: org.jboss.msc.service.StartException in service ServiceActivatorDeployment.c: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 	at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "interrelated-c.jar" "write")" in code source "(vfs:/content/interrelated-a.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.interrelated-a.jar" from Service Module Loader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.System.setProperty(System.java:792)
> 	at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:91)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	... 4 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:18:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 1 Feb 2017 06:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8007) Replace WorkManager
 elytron-enabled atttribute by elytron-security-domain
In-Reply-To: <JIRA.12674108.1485947862000@Atlassian.JIRA>
References: <JIRA.12674108.1485947862000@Atlassian.JIRA>
	<JIRA.12674108.1485947862125@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674108.1485947862000.39726.1485947880596@Atlassian.JIRA>

Flavia Rainone created WFLY-8007:
------------------------------------

             Summary: Replace WorkManager elytron-enabled atttribute by elytron-security-domain
                 Key: WFLY-8007
                 URL: https://issues.jboss.org/browse/WFLY-8007
             Project: WildFly
          Issue Type: Enhancement
          Components: JCA
            Reporter: Flavia Rainone
            Assignee: Stefano Maestri


Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:43:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 06:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949332000@Atlassian.JIRA>
References: <JIRA.12674123.1485949332000@Atlassian.JIRA>
	<JIRA.12674123.1485949332614@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949332000.40064.1485949380626@Atlassian.JIRA>

Ondrej Lukas created ELY-903:
--------------------------------

             Summary: Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
                 Key: ELY-903
                 URL: https://issues.jboss.org/browse/ELY-903
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.

Most important part of ldif for reproduction is following:
{code}
dn: cn=R1,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R1
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the R1 group

dn: cn=R2,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R2
member: uid=jduke,ou=People,dc=jboss,dc=org
member: cn=R1,ou=Roles,dc=jboss,dc=org
description: the R2 group

dn: cn=R3,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R3
member: cn=R2,ou=Roles,dc=jboss,dc=org
description: the R3 group
{code}
User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:43:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 06:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.40069.1485949380813@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-903:
-----------------------------
    Affects Version/s: 1.1.0.Beta21


> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:43:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 06:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.40079.1485949381071@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-903:
-----------------------------
    Component/s: Realms


> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 06:44:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 1 Feb 2017 06:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.40098.1485949441440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-903:
-----------------------------
    Attachment: print-roles.war


> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 07:26:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 1 Feb 2017 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1539) NAKACK2: xmit_interval
 sometimes triggers unneeded retransmissions
In-Reply-To: <JIRA.12479006.1352734543000@Atlassian.JIRA>
References: <JIRA.12479006.1352734543000@Atlassian.JIRA>
	<JIRA.12479006.1352734543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479006.1352734543000.40501.1485951960289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1539:
---------------------------
    Description: 
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received

Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.

The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.

Another reason is also that the message bundler on the sender side might send messages in random order (see link below).

SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.

  was:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received

Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Has the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.

The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.

Another reason is also that the message bundler on the sender side might send messages in random order (see link below).

SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.



> NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
> ------------------------------------------------------------------
>
>                 Key: JGRP-1539
>                 URL: https://issues.jboss.org/browse/JGRP-1539
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.3
>
>
> In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message. 
> Example:
> - Messages 1,2,3,4,5 are received at time T0 (in ms)
> - At time T1000, message 20 is received
> - At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
> - At time T1009, messages 6-19 are received
> Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
> The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
> Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
> SOLUTION:
> Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 07:58:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 07:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2252) AttributeDefinition should
 reject configs with a default value that are also set as required
In-Reply-To: <JIRA.12674029.1485900511000@Atlassian.JIRA>
References: <JIRA.12674029.1485900511000@Atlassian.JIRA>
	<JIRA.12674029.1485900511000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674029.1485900511000.40671.1485953881139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2252:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1


Moving to consideration in WildFly Core 4. Too disruptive at this stage for 3.

> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2252
>                 URL: https://issues.jboss.org/browse/WFCORE-2252
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject this combination in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 07:59:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 07:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2252) AttributeDefinition should
 reject configs with a default value that are also set as required
In-Reply-To: <JIRA.12674029.1485900511000@Atlassian.JIRA>
References: <JIRA.12674029.1485900511000@Atlassian.JIRA>
	<JIRA.12674029.1485900511000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674029.1485900511000.40682.1485953941471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2252:
-------------------------------------
    Description: 
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.

AttributeDefinition should reject the combination of a default value and required=true in its constructor.

I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.

  was:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.

AttributeDefinition should reject this combination in its constructor.

I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.



> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2252
>                 URL: https://issues.jboss.org/browse/WFCORE-2252
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject the combination of a default value and required=true in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 08:06:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 1 Feb 2017 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8008) Upgrade to Elytron Subsystem
	1.0.0.Beta4
In-Reply-To: <JIRA.12674146.1485954308000@Atlassian.JIRA>
References: <JIRA.12674146.1485954308000@Atlassian.JIRA>
	<JIRA.12674146.1485954308394@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674146.1485954308000.40726.1485954360453@Atlassian.JIRA>

Darran Lofthouse created WFLY-8008:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Beta4
                 Key: WFLY-8008
                 URL: https://issues.jboss.org/browse/WFLY-8008
             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  Wed Feb  1 08:19:00 2017
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 1 Feb 2017 08:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1987) Create request/response
 reporting mechanism
In-Reply-To: <JIRA.12661633.1479199869000@Atlassian.JIRA>
References: <JIRA.12661633.1479199869000@Atlassian.JIRA>
	<JIRA.12661633.1479199869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661633.1479199869000.40949.1485955140654@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356268#comment-13356268 ] 

Bartosz Baranowski commented on WFCORE-1987:
--------------------------------------------

[~brian.stansberry] I think I figured out the reason for silent treatment of inactive profile.
Just to clarify, I run existing domain.xml conf/xml, with some small change - Ive added worker 'xxx'.  
In in CLI 
{noformat}
cd profile=default/subsystem=undertow/server=default-server/http-listener=default
:write-attribute(name=worker,value=xxx)
{noformat}
When operation hit controller primaryAnswer is set to value from step with PrepareStepHandler: {"outcome" => undefined}. (A1) 
https://github.com/wildfly/wildfly-core/blame/master/controller/src/main/java/org/jboss/as/controller/AbstractOperationContext.java#L655
This value is the same for next step, with DomainFinalResultHandler.
There is another value created in  https://github.com/wildfly/wildfly-core/blame/master/host-controller/src/main/java/org/jboss/as/domain/controller/operations/coordination/OperationSlaveStepHandler.java#L126 (A2). 
The A2 is actually one that is being edited in WriteAttributeHandler - this one contain proper answer to operation. 
When DomainFinalResultHandler kicks in, it gets both values:
- A1: https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/domain/controller/operations/coordination/DomainFinalResultHandler.java#L97
- A2: https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/main/java/org/jboss/as/domain/controller/operations/coordination/DomainFinalResultHandler.java#L106

Im kind of trying to figure out what getDomainResults method is supposed to parse, but all it return is "undefined" regardless of any content (outcome->success and other nodes) in A2, and populate it into A1.

If profile is active, whole thing is saved by "serverResults" which is not empty in this case and contain ~same result as A1.

Any thoughts?

> Create request/response reporting mechanism
> -------------------------------------------
>
>                 Key: WFCORE-1987
>                 URL: https://issues.jboss.org/browse/WFCORE-1987
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Remoting
>            Reporter: Radim Hatlapatka
>            Assignee: Bartosz Baranowski
>              Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Scope of this enhancement are:
> a) way to send back information
> b) control level of "information" - just like in case of loggers
> a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID.
> b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level
> Example:
> {noformat}
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "warnings" => [
>             {
>                 "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
>                 "level" => "ALL",
>                 "operation" => {
>                     "address" => [
>                         ("subsystem" => "undertow"),
>                         ("server" => "default-server"),
>                         ("http-listener" => "default")
>                     ],
>                     "operation" => "write-attribute"
>                 }
>             },
>             {
>                 "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.",
>                 "level" => "WARNING",
>                 "operation" => {
>                     "address" => [
>                         ("subsystem" => "undertow"),
>                         ("server" => "default-server"),
>                         ("http-listener" => "default")
>                     ],
>                     "operation" => "write-attribute"
>                 }
>             }
>         ],
>         "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  Wed Feb  1 08:32:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 1 Feb 2017 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7948) Credential Store intergration
 into RA subsystem
In-Reply-To: <JIRA.12672653.1485249235000@Atlassian.JIRA>
References: <JIRA.12672653.1485249235000@Atlassian.JIRA>
	<JIRA.12672653.1485249235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672653.1485249235000.41194.1485955920253@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated WFLY-7948:
-------------------------------
    Summary: Credential Store intergration into RA subsystem  (was: Crefential Store intergration into RA subsystem)


> Credential Store intergration into RA subsystem
> -----------------------------------------------
>
>                 Key: WFLY-7948
>                 URL: https://issues.jboss.org/browse/WFLY-7948
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 09:09:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 1 Feb 2017 09:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout support for HTTP-based
 authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124219@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.41706.1485958140116@Atlassian.JIRA>

Pedro Igor created ELY-904:
------------------------------

             Summary: Logout support for HTTP-based authentication mechanisms
                 Key: ELY-904
                 URL: https://issues.jboss.org/browse/ELY-904
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: HTTP
    Affects Versions: 1.1.0.Beta21
            Reporter: Pedro Igor
            Assignee: Pedro Igor


I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.

Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.

The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 09:12:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 1 Feb 2017 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout support for HTTP-based
 authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.41740.1485958320498@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-904:
---------------------------
    Description: 
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.

Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.

The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.

Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.

  was:
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.

Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.

The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.



> Logout support for HTTP-based authentication mechanisms
> -------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:13:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 1 Feb 2017 10:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7653) Validate session-timeout and
 maximum-session-cache-size to be non-negative
In-Reply-To: <JIRA.12663211.1479888953000@Atlassian.JIRA>
References: <JIRA.12663211.1479888953000@Atlassian.JIRA>
	<JIRA.12663211.1479888953000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663211.1479888953000.42340.1485961980352@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reopened WFLY-7653:
---------------------------------


Missing change in XSD clientSSLContextType.

> Validate session-timeout and maximum-session-cache-size to be non-negative
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7653
>                 URL: https://issues.jboss.org/browse/WFLY-7653
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 11.0.0.Alpha1
>
>
> Negative values are invalid in this case because they do not make sense for these attributes. Also java throws IllegalArgumentException, when they get negative values on that place. [1]
> Please add validation to limit these values to zero and positive values in:
> * model 
> * XSD
> That applies for both:
> * client-ssl-context 
> * server-ssl-context
> [1] http://www.ibm.com/support/knowledgecenter/SSVHEW_6.2.0/com.ibm.rcp.dee.javadoc/doc/javax/net/ssl/SSLSessionContext.html



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:15:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-905) Authentication based on
 certificates does not work in Elytron with Undertow
In-Reply-To: <JIRA.12664044.1480344317000@Atlassian.JIRA>
References: <JIRA.12664044.1480344317000@Atlassian.JIRA>
	<JIRA.12664044.1480344317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664044.1480344317000.42350.1485962100425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7687 to ELY-905:
--------------------------------------

          Project: WildFly Elytron  (was: WildFly)
              Key: ELY-905  (was: WFLY-7687)
      Component/s: HTTP
                       (was: Security)
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
>                 Key: ELY-905
>                 URL: https://issues.jboss.org/browse/ELY-905
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>         Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	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 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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: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.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> 	... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [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/master/src/main/java/org/wildfly/security/http/HttpConstants.java#L93
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/impl/ClientCertAuthenticationMechanism.java#L66



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:15:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-905) Authentication based on
 certificates does not work in Elytron with Undertow
In-Reply-To: <JIRA.12664044.1480344317000@Atlassian.JIRA>
References: <JIRA.12664044.1480344317000@Atlassian.JIRA>
	<JIRA.12664044.1480344317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664044.1480344317000.42358.1485962100758@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-905:
---------------------------
    Affects Version/s: 1.1.0.Beta21


> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
>                 Key: ELY-905
>                 URL: https://issues.jboss.org/browse/ELY-905
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>         Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	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 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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: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.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> 	... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [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/master/src/main/java/org/wildfly/security/http/HttpConstants.java#L93
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/impl/ClientCertAuthenticationMechanism.java#L66



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:17:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 1 Feb 2017 10:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7653) Validate session-timeout and
 maximum-session-cache-size to be non-negative
In-Reply-To: <JIRA.12663211.1479888953000@Atlassian.JIRA>
References: <JIRA.12663211.1479888953000@Atlassian.JIRA>
	<JIRA.12663211.1479888953000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663211.1479888953000.42417.1485962221849@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated WFLY-7653:
--------------------------------
    Fix Version/s:     (was: 11.0.0.Alpha1)


> Validate session-timeout and maximum-session-cache-size to be non-negative
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7653
>                 URL: https://issues.jboss.org/browse/WFLY-7653
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>
> Negative values are invalid in this case because they do not make sense for these attributes. Also java throws IllegalArgumentException, when they get negative values on that place. [1]
> Please add validation to limit these values to zero and positive values in:
> * model 
> * XSD
> That applies for both:
> * client-ssl-context 
> * server-ssl-context
> [1] http://www.ibm.com/support/knowledgecenter/SSVHEW_6.2.0/com.ibm.rcp.dee.javadoc/doc/javax/net/ssl/SSLSessionContext.html



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:18:02 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 1 Feb 2017 10:18:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout support for HTTP-based
 authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.42453.1485962282678@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356430#comment-13356430 ] 

Pedro Igor commented on ELY-904:
--------------------------------

Maybe we may consider an interface {{StatefulHttpServerAuthenticationMechanism}} which provides the ability to implement mechanisms that track user authentication session and support logout.

> Logout support for HTTP-based authentication mechanisms
> -------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:20:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 10:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-905) Authentication based on
 certificates does not work in Elytron with Undertow
In-Reply-To: <JIRA.12664044.1480344317000@Atlassian.JIRA>
References: <JIRA.12664044.1480344317000@Atlassian.JIRA>
	<JIRA.12664044.1480344317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664044.1480344317000.42537.1485962400680@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356433#comment-13356433 ] 

Jan Kalina commented on ELY-905:
--------------------------------

Honza Kalina: the UndertowDeploymentInfoService converts authentication method names from "format in web.xml" (CLIENT-CERT) to "format used by HttpServletRequest" (CLIENT_CERT) - which of them should be passed/accepted by Elytron? can I modify elytron to accept both of them?
Darran Lofthouse: As in servlet spec we are required to report the name in the format defined in HttpServletRequest then it probably makes sense for our mech and factory to use that format.??I would suggest that means we convert from web.xml format to API format.??Withing our mech factory report we support CLINET_CERT but maybe also be tollerant if we are called to create a mech with CLIENT-CERT
David M. Lloyd: I never like the "accept both" strategy - I'd rather see one be declared "correct"
Darran Lofthouse: I think the primary one needs to be *the one from HttpServletRequest* and convert from the one in web.xml - if we don't want to be tolerant stick with just that

> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
>                 Key: ELY-905
>                 URL: https://issues.jboss.org/browse/ELY-905
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>         Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	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 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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: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.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> 	... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [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/master/src/main/java/org/wildfly/security/http/HttpConstants.java#L93
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/impl/ClientCertAuthenticationMechanism.java#L66



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  1 10:21:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 1 Feb 2017 10:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with
 security manager - Reenable the test
In-Reply-To: <JIRA.12660396.1478689560000@Atlassian.JIRA>
References: <JIRA.12660396.1478689560000@Atlassian.JIRA>
	<JIRA.12660396.1478689560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660396.1478689560000.42562.1485962461988@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reopened WFLY-7538:
-----------------------------
      Assignee: Josef Cacek  (was: Darran Lofthouse)


{{WebSocketTestCase}} is correctly enabled. However, {{testClientInDeployment}} fails with security manager. The output is following:

{code}
SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testClientInDeployment: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "localhost:0" "listen,resolve")" in code source "(vfs:/content/indeployment.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.indeployment.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.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:344)
	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.assertWebSocket(WebSocketTestCase.java:81)
	at org.jboss.as.test.integration.web.websocket.WebSocketTestCase.testClientInDeployment(WebSocketTestCase.java:75)
	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: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)
{code}

This happens only if {{-Dnode0}} parameter is used (e.g. in QE's CI). Here are steps to reproduce:
# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dtest=WebSocketTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

>From my observation it appears that {{localhost}} value in a SocketPermission as discussed in [this comment|https://issues.jboss.org/browse/WFLY-7538?focusedCommentId=13327673&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13327673] must be hardcoded instead of using {{TestSuiteEnvironment.getServerAddress()}}. If {{-Dnode0}} parameter is omitted both tests pass.


See JBEAP-7011 for more details

> WebSocketTestCase fails with security manager - Reenable the test
> -----------------------------------------------------------------
>
>                 Key: WFLY-7538
>                 URL: https://issues.jboss.org/browse/WFLY-7538
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Josef Cacek
>            Priority: Blocker
>              Labels: downstream_dependency
>             Fix For: 11.0.0.Alpha1
>
>
> Reenable WebSocketsTestCase. See WFLY-7539 for more details



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:21:02 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 1 Feb 2017 10:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with
 security manager - Reenable the test
In-Reply-To: <JIRA.12660396.1478689560000@Atlassian.JIRA>
References: <JIRA.12660396.1478689560000@Atlassian.JIRA>
	<JIRA.12660396.1478689560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660396.1478689560000.42578.1485962462582@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFLY-7538:
----------------------------
    Priority: Major  (was: Blocker)


> WebSocketTestCase fails with security manager - Reenable the test
> -----------------------------------------------------------------
>
>                 Key: WFLY-7538
>                 URL: https://issues.jboss.org/browse/WFLY-7538
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Josef Cacek
>              Labels: downstream_dependency
>             Fix For: 11.0.0.Alpha1
>
>
> Reenable WebSocketsTestCase. See WFLY-7539 for more details



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 10:21:03 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 1 Feb 2017 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7538) WebSocketTestCase fails with
 security manager - Reenable the test
In-Reply-To: <JIRA.12660396.1478689560000@Atlassian.JIRA>
References: <JIRA.12660396.1478689560000@Atlassian.JIRA>
	<JIRA.12660396.1478689560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660396.1478689560000.42601.1485962463516@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFLY-7538:
----------------------------
    Component/s: Test Suite
                     (was: Security)


> WebSocketTestCase fails with security manager - Reenable the test
> -----------------------------------------------------------------
>
>                 Key: WFLY-7538
>                 URL: https://issues.jboss.org/browse/WFLY-7538
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Kabir Khan
>            Assignee: Josef Cacek
>              Labels: downstream_dependency
>             Fix For: 11.0.0.Alpha1
>
>
> Reenable WebSocketsTestCase. See WFLY-7539 for more details



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 11:28:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 11:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.43186.1485966481322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7843:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 11:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 11:34: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: <JIRA.12673421.1485526190000@Atlassian.JIRA>
References: <JIRA.12673421.1485526190000@Atlassian.JIRA>
	<JIRA.12673421.1485526190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673421.1485526190000.43244.1485966840452@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356844#comment-13356844 ] 

Brian Stansberry commented on WFLY-7983:
----------------------------------------

What happens with

embed-server --admin-only=false

or

bin/standalone.sh --admin-only

?

If it works in the former and not in the latter please edit this to be about whether it should work in admin-only, and not specifically about embed-server. I haven't thought about whether it should or shouldn't so I have no opinion now. ;)

> 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.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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  1 11:40:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.43315.1485967200668@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356856#comment-13356856 ] 

Jan Kalina commented on WFLY-7843:
----------------------------------

It is possible to override this using generic options exposed as part of WFLY-7720:
{code:xml}
  <dir-context name="DirContext" ...>
     <properties>
        <property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
     </properties>
  </dir-context>
{code}


> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 11:42:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 1 Feb 2017 11:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.43351.1485967321460@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-7843.
----------------------------
    Resolution: Rejected


Rejected, see workaround above.
Feel free to reopen if complete class reference (module + class) would be required.

> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 11:56:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 1 Feb 2017 11:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7973) WildFlyDataSource needs
 implementation of isWrapperFor method
In-Reply-To: <JIRA.12673055.1485362834000@Atlassian.JIRA>
References: <JIRA.12673055.1485362834000@Atlassian.JIRA>
	<JIRA.12673055.1485362834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673055.1485362834000.43444.1485968160724@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356876#comment-13356876 ] 

RH Bugzilla Integration commented on WFLY-7973:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1416564|https://bugzilla.redhat.com/show_bug.cgi?id=1416564] from ASSIGNED to CLOSED

> WildFlyDataSource needs implementation of isWrapperFor method
> -------------------------------------------------------------
>
>                 Key: WFLY-7973
>                 URL: https://issues.jboss.org/browse/WFLY-7973
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 10.1.0.Final
>            Reporter: Johnathon Lee
>            Assignee: Ivo Studensky
>
> inability to determine datasource vs xa-datasource after JNDI lookup.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 12:47:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2160) Incorrect JBOSS_HOME
	warning in vault.sh
In-Reply-To: <JIRA.12669817.1483736154000@Atlassian.JIRA>
References: <JIRA.12669817.1483736154000@Atlassian.JIRA>
	<JIRA.12669817.1483736154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669817.1483736154000.43828.1485971220828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reopened WFCORE-2160:
--------------------------------------


> Incorrect JBOSS_HOME warning in vault.sh
> ----------------------------------------
>
>                 Key: WFCORE-2160
>                 URL: https://issues.jboss.org/browse/WFCORE-2160
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Dennis Reed
>            Assignee: Romain Pelisse
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> vault.sh has an incorrect check to make sure JBOSS_HOME is set correctly.
>     SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME/.."; pwd`
>     if [ "$RESOLVED_JBOSS" != "$SANITIZED_JBOSS_HOME" ]; then
> The check will always fail because of the incorrect "/..", which should be removed.
> The incorrect value is only used for printing the "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." log, and appears to have been around since at least EAP 6.0.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 12:47:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2160) Incorrect JBOSS_HOME
	warning in vault.sh
In-Reply-To: <JIRA.12669817.1483736154000@Atlassian.JIRA>
References: <JIRA.12669817.1483736154000@Atlassian.JIRA>
	<JIRA.12669817.1483736154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669817.1483736154000.43834.1485971220960@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-2160.
--------------------------------------
    Fix Version/s: 3.0.0.Alpha23
                       (was: 3.0.0.Alpha20)
       Resolution: Done


> Incorrect JBOSS_HOME warning in vault.sh
> ----------------------------------------
>
>                 Key: WFCORE-2160
>                 URL: https://issues.jboss.org/browse/WFCORE-2160
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Dennis Reed
>            Assignee: Romain Pelisse
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> vault.sh has an incorrect check to make sure JBOSS_HOME is set correctly.
>     SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME/.."; pwd`
>     if [ "$RESOLVED_JBOSS" != "$SANITIZED_JBOSS_HOME" ]; then
> The check will always fail because of the incorrect "/..", which should be removed.
> The incorrect value is only used for printing the "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." log, and appears to have been around since at least EAP 6.0.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 12:48:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 12:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2160) Incorrect JBOSS_HOME
	warning in vault.sh
In-Reply-To: <JIRA.12669817.1483736154000@Atlassian.JIRA>
References: <JIRA.12669817.1483736154000@Atlassian.JIRA>
	<JIRA.12669817.1483736154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669817.1483736154000.43838.1485971280651@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2160:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2076, https://github.com/wildfly/wildfly-core/pull/2140  (was: https://github.com/wildfly/wildfly-core/pull/2076)


> Incorrect JBOSS_HOME warning in vault.sh
> ----------------------------------------
>
>                 Key: WFCORE-2160
>                 URL: https://issues.jboss.org/browse/WFCORE-2160
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Dennis Reed
>            Assignee: Romain Pelisse
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> vault.sh has an incorrect check to make sure JBOSS_HOME is set correctly.
>     SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME/.."; pwd`
>     if [ "$RESOLVED_JBOSS" != "$SANITIZED_JBOSS_HOME" ]; then
> The check will always fail because of the incorrect "/..", which should be removed.
> The incorrect value is only used for printing the "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." log, and appears to have been around since at least EAP 6.0.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 13:02:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 1 Feb 2017 13:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-906)
 SetCallbackHandlerAuthenticationConfiguration should support all sasl
 mechanisms
In-Reply-To: <JIRA.12674248.1485972105000@Atlassian.JIRA>
References: <JIRA.12674248.1485972105000@Atlassian.JIRA>
	<JIRA.12674248.1485972105968@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674248.1485972105000.43909.1485972120718@Atlassian.JIRA>

Darran Lofthouse created ELY-906:
------------------------------------

             Summary: SetCallbackHandlerAuthenticationConfiguration should support all sasl mechanisms
                 Key: ELY-906
                 URL: https://issues.jboss.org/browse/ELY-906
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Authentication Client
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta22


SetCallbackHandlerAuthenticationConfiguration should however not override the saslAllowedByConfiguration as that is policy.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 13:50:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 13:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1855) Possible NPE on controller
	service start
In-Reply-To: <JIRA.12653404.1475674570000@Atlassian.JIRA>
References: <JIRA.12653404.1475674570000@Atlassian.JIRA>
	<JIRA.12653404.1475674570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653404.1475674570000.44053.1485975000277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1855:
----------------------------------------

    Assignee: Brian Stansberry


> Possible NPE on controller service start
> ----------------------------------------
>
>                 Key: WFCORE-1855
>                 URL: https://issues.jboss.org/browse/WFCORE-1855
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: David Lloyd
>            Assignee: Brian Stansberry
>
> In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process.  Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method.
> Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked.  This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method.
> The problem arises when the service itself is stopped before the boot thread completes.  This causes the {{controller}} field to be nulled out, resulting in an NPE.
> I think we need to look at:
> * Why are we using a background thread for this?
> * Why are we _not_ using the asynchronous startup feature?
> I think we must do one of these two things in order to make this code "safe".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 13:55:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 13:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1855) Possible NPE on controller
	service start
In-Reply-To: <JIRA.12653404.1475674570000@Atlassian.JIRA>
References: <JIRA.12653404.1475674570000@Atlassian.JIRA>
	<JIRA.12653404.1475674570000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653404.1475674570000.44066.1485975300353@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13356964#comment-13356964 ] 

Brian Stansberry commented on WFCORE-1855:
------------------------------------------

https://github.com/bstansberry/wildfly-core/tree/WFCORE-1855 is WIP on this. Kind of a workaround. I opened up a PR for it but I think I'll withdraw it for now as it's a bit out of date and I don't feel urgency to get this particular solution in.

> Possible NPE on controller service start
> ----------------------------------------
>
>                 Key: WFCORE-1855
>                 URL: https://issues.jboss.org/browse/WFCORE-1855
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: David Lloyd
>            Assignee: Brian Stansberry
>
> In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up a background thread which performs a certain amount of the boot process.  Before this thread is started, a volatile field {{controller}} is initialized with the controller reported by the {{start()}} method.
> Inside this thread, some work is performed, and at the end of a certain amount of work, the {{finishBoot()}} method is invoked.  This method calls {{controller.finishBoot()}}, referencing the field that was set in the {{start()}} method.
> The problem arises when the service itself is stopped before the boot thread completes.  This causes the {{controller}} field to be nulled out, resulting in an NPE.
> I think we need to look at:
> * Why are we using a background thread for this?
> * Why are we _not_ using the asynchronous startup feature?
> I think we must do one of these two things in order to make this code "safe".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 13:59:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 1 Feb 2017 13:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2255) Upgrade to WildFly Common
	1.2.0.Beta5
In-Reply-To: <JIRA.12674252.1485975487000@Atlassian.JIRA>
References: <JIRA.12674252.1485975487000@Atlassian.JIRA>
	<JIRA.12674252.1485975487951@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674252.1485975487000.44077.1485975540410@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2255:
----------------------------------------

             Summary: Upgrade to WildFly Common 1.2.0.Beta5
                 Key: WFCORE-2255
                 URL: https://issues.jboss.org/browse/WFCORE-2255
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 14:57:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2223) Setting JBOSS_MODULEPATH is
 lost for second start of embed-server
In-Reply-To: <JIRA.12672331.1484929128000@Atlassian.JIRA>
References: <JIRA.12672331.1484929128000@Atlassian.JIRA>
	<JIRA.12672331.1484929128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672331.1484929128000.44369.1485979020355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2223:
----------------------------------------

    Fix Version/s: 3.0.0.Alpha23
         Assignee: Brian Stansberry  (was: Jean-Francois Denise)
       Resolution: Done


> Setting JBOSS_MODULEPATH is lost for second start of embed-server
> -----------------------------------------------------------------
>
>                 Key: WFCORE-2223
>                 URL: https://issues.jboss.org/browse/WFCORE-2223
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Server
>            Reporter: Josef Cacek
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 3.0.0.Alpha23
>
>
> When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
> The subsequent `embed-server` call results in error:
> {code}
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
> {code}
> Using the  {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#define_an_external_jboss_eap_module_directory



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 14:59:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 14:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2216) CLI fails to reload when
 connection upgrades from http to https
In-Reply-To: <JIRA.12672103.1484843632000@Atlassian.JIRA>
References: <JIRA.12672103.1484843632000@Atlassian.JIRA>
	<JIRA.12672103.1484843632000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672103.1484843632000.44384.1485979140240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2216:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2126  (was: https://github.com/wildfly/wildfly-core/pull/2113)


> CLI fails to reload when connection upgrades from http to https
> ---------------------------------------------------------------
>
>                 Key: WFCORE-2216
>                 URL: https://issues.jboss.org/browse/WFCORE-2216
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>
> reload command should manage to reconnect to a server reconfigured with https management interface.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 19:06:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 1 Feb 2017 19:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2256) Undertow 1.4.10.Final
In-Reply-To: <JIRA.12674289.1485993931000@Atlassian.JIRA>
References: <JIRA.12674289.1485993931000@Atlassian.JIRA>
	<JIRA.12674289.1485993931044@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674289.1485993931000.45052.1485993960091@Atlassian.JIRA>

Stuart Douglas created WFCORE-2256:
--------------------------------------

             Summary: Undertow 1.4.10.Final
                 Key: WFCORE-2256
                 URL: https://issues.jboss.org/browse/WFCORE-2256
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 19:49:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 19:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2089) Infinite wildfly boot on
 StartException in service start
In-Reply-To: <JIRA.12665631.1481036827000@Atlassian.JIRA>
References: <JIRA.12665631.1481036827000@Atlassian.JIRA>
	<JIRA.12665631.1481036827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665631.1481036827000.45068.1485996540467@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2089:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2143  (was: https://github.com/wildfly/wildfly-core/pull/2053)


> Infinite wildfly boot on StartException in service start
> --------------------------------------------------------
>
>                 Key: WFCORE-2089
>                 URL: https://issues.jboss.org/browse/WFCORE-2089
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Kalina
>            Assignee: ehsavoie Hugonnet
>            Priority: Blocker
>         Attachments: threads-2.txt, threads.txt
>
>
> Following exception (and probably similar too) will cause wildfly frozing during start. Visible especially during integration tests (which will never ends), but reproducible directly too (see steps).
> {code:java}
> 15:59:37,252 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in password property file
> 	at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:185)
> 	at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:164)
> 	at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> 	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)
> {code}
> *Update:* This problem with infinite boot will occure everytime the start() method of some service throws StartException(). Not an Elytron problem.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 19:51:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 19:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2238) Drop the inflowed security
 domains attribute from access=identity
In-Reply-To: <JIRA.12673487.1485543120000@Atlassian.JIRA>
References: <JIRA.12673487.1485543120000@Atlassian.JIRA>
	<JIRA.12673487.1485543120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673487.1485543120000.45094.1485996660339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2238:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2143  (was: https://github.com/wildfly/wildfly-core/pull/2134)


> Drop the inflowed security domains attribute from access=identity
> -----------------------------------------------------------------
>
>                 Key: WFCORE-2238
>                 URL: https://issues.jboss.org/browse/WFCORE-2238
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha23
>
>
> We may restore it later so don't remove the code that uses it but remove it from the management model.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:11:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 22:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1987) Create request/response
 reporting mechanism
In-Reply-To: <JIRA.12661633.1479199869000@Atlassian.JIRA>
References: <JIRA.12661633.1479199869000@Atlassian.JIRA>
	<JIRA.12661633.1479199869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661633.1479199869000.45181.1486005060247@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357107#comment-13357107 ] 

Brian Stansberry commented on WFCORE-1987:
------------------------------------------

I would expect getDomainResults to return an undefined node for a write-attribute call. The key thing is it's concerned with the *result* child of the response that goes to the user, not the complete response. The result of a write-attribute is 'undefined':

{code}
{
  "outcome" => "success",
  "result" => undefined
}
{code}

Does the A2 node have the warnings you expect? If so you'll need to propagate those to A1 by reading them from A2 and calling context.addWarning, similarly to how it currently reads the result from A2 and passes it to A1 by calling context.getResult().set(...)

What needs thought is how to deal with warnings that come from slave HCs and from the servers as part of domain rollout. My impression from your comments is that in the case of servers, the 'server-results' structure is showing the warnings from the servers, as part of each server's response. Correct? If so, that sounds ok.

For these domain rollout ops, I think it's fine to ignore warnings from the slave HCs. They should be redundant, same as what the master generated in your A2 response.

All this is about ops that result in a domain-wide rollout (i.e. that go the OperationCoordinatorStepHandler.executeTwoPhaseOperation path). This feature also needs to deal with ops that go the executeDirect path or that are proxied steps in a composite that goes the executeTwoPhaseOperation. That is

/host=slave:do-something-that-generates-a-warn

or

/host=slave/server=a:do-something-that-generates-a-warn

or

/host=master/server=a:do-something-that-generates-a-warn

Aha! It looks like that is largely handled. See ProxyStepHandler L199-201 -- any headers from the proxied process are copied into the local response.

This will all need to be verified via tests.

> Create request/response reporting mechanism
> -------------------------------------------
>
>                 Key: WFCORE-1987
>                 URL: https://issues.jboss.org/browse/WFCORE-1987
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Remoting
>            Reporter: Radim Hatlapatka
>            Assignee: Bartosz Baranowski
>              Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Scope of this enhancement are:
> a) way to send back information
> b) control level of "information" - just like in case of loggers
> a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID.
> b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level
> Example:
> {noformat}
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "warnings" => [
>             {
>                 "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
>                 "level" => "ALL",
>                 "operation" => {
>                     "address" => [
>                         ("subsystem" => "undertow"),
>                         ("server" => "default-server"),
>                         ("http-listener" => "default")
>                     ],
>                     "operation" => "write-attribute"
>                 }
>             },
>             {
>                 "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.",
>                 "level" => "WARNING",
>                 "operation" => {
>                     "address" => [
>                         ("subsystem" => "undertow"),
>                         ("server" => "default-server"),
>                         ("http-listener" => "default")
>                     ],
>                     "operation" => "write-attribute"
>                 }
>             }
>         ],
>         "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  Wed Feb  1 22:15:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 22:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2256) Undertow 1.4.10.Final
In-Reply-To: <JIRA.12674289.1485993931000@Atlassian.JIRA>
References: <JIRA.12674289.1485993931000@Atlassian.JIRA>
	<JIRA.12674289.1485993931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674289.1485993931000.45189.1486005300207@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2256:
----------------------------------------

    Fix Version/s: 3.0.0.Alpha23
         Assignee: Stuart Douglas
       Resolution: Done


> Undertow 1.4.10.Final
> ---------------------
>
>                 Key: WFCORE-2256
>                 URL: https://issues.jboss.org/browse/WFCORE-2256
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 3.0.0.Alpha23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:17:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 1 Feb 2017 22:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8009) Write a test for Resource
 Adapters using Elytron
In-Reply-To: <JIRA.12674291.1486005407000@Atlassian.JIRA>
References: <JIRA.12674291.1486005407000@Atlassian.JIRA>
	<JIRA.12674291.1486005407670@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674291.1486005407000.45193.1486005420065@Atlassian.JIRA>

Flavia Rainone created WFLY-8009:
------------------------------------

             Summary: Write a test for Resource Adapters using Elytron
                 Key: WFLY-8009
                 URL: https://issues.jboss.org/browse/WFLY-8009
             Project: WildFly
          Issue Type: Enhancement
          Components: JCA
            Reporter: Flavia Rainone


Write a basic test case to make sure everything needed to make Resource Adapters + Elytron work is in place.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:18:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 22:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version
 1.7.7.jbossorg-1 to 1.7.22
In-Reply-To: <JIRA.12635197.1466804517000@Atlassian.JIRA>
References: <JIRA.12635197.1466804517000@Atlassian.JIRA>
	<JIRA.12635197.1466804517000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12635197.1466804517000.45200.1486005480258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1620:
-------------------------------------
    Fix Version/s: 2.2.1.Final


> Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
> -----------------------------------------------------
>
>                 Key: WFCORE-1620
>                 URL: https://issues.jboss.org/browse/WFCORE-1620
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: Frank Langelage
>             Fix For: 3.0.0.Alpha18, 2.2.1.Final
>
>
> There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
> [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
> {quote}
> The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
> {quote}
> Analysis will need to be done to ensure this works as expected before the fork is no longer required.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:25:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 1 Feb 2017 22:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8007) Replace WorkManager
 elytron-enabled atttribute by elytron-security-domain
In-Reply-To: <JIRA.12674108.1485947862000@Atlassian.JIRA>
References: <JIRA.12674108.1485947862000@Atlassian.JIRA>
	<JIRA.12674108.1485947862000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674108.1485947862000.45213.1486005900229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned WFLY-8007:
------------------------------------

    Assignee: James Perkins  (was: Stefano Maestri)


[~jamezp], do you think you will have time to look into this other Capability-related issue before the next release? Let me know if that's not the case, either I or [~maeste] will work on this Jira. Thanks a lot!

> Replace WorkManager elytron-enabled atttribute by elytron-security-domain
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8007
>                 URL: https://issues.jboss.org/browse/WFLY-8007
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: James Perkins
>
> Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:28:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 1 Feb 2017 22:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8010) Write a test for DataSources
	with Elytron
In-Reply-To: <JIRA.12674292.1486006043000@Atlassian.JIRA>
References: <JIRA.12674292.1486006043000@Atlassian.JIRA>
	<JIRA.12674292.1486006043491@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674292.1486006043000.45219.1486006080118@Atlassian.JIRA>

Flavia Rainone created WFLY-8010:
------------------------------------

             Summary: Write a test for DataSources with Elytron
                 Key: WFLY-8010
                 URL: https://issues.jboss.org/browse/WFLY-8010
             Project: WildFly
          Issue Type: Enhancement
          Components: JCA
            Reporter: Flavia Rainone
            Assignee: Stefano Maestri


Write a basic test case to make sure everything needed to make DataSources + Elytron work is in place.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  1 22:43:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 1 Feb 2017 22:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2253) Some AttributeDefinition
 instances are configured with default values but say they are required
In-Reply-To: <JIRA.12674032.1485908259000@Atlassian.JIRA>
References: <JIRA.12674032.1485908259000@Atlassian.JIRA>
	<JIRA.12674032.1485908259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674032.1485908259000.45264.1486006980194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2253:
----------------------------------------

    Assignee: Brian Stansberry


> Some AttributeDefinition instances are configured with default values but say they are required
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2253
>                 URL: https://issues.jboss.org/browse/WFCORE-2253
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> An AD with a default value does not require the user to set it, so configuring it with required = true fka allowNull = false is incorrect. WFCORE-2252 proposes to reject these. This is to clean them up first. 
> Note that for any such attributes, if they existed in a previous release a transformer must be written to go along with a change to required=false. Even though they had a default before, the required=true setting made it as if it didn't exist, so this change is the same as adding a default



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 00:35:00 2017
From: issues at jboss.org (Hisanobu Okuda (JIRA))
Date: Thu, 2 Feb 2017 00:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.45329.1486013700919@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hisanobu Okuda updated WFLY-3858:
---------------------------------


> 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: Darran Lofthouse
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> 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<Map, Principal> cm = (CacheableManager<Map, Principal>) 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 Feb  2 02:14:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 2 Feb 2017 02:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2257) Missing username in LDAP
 entry for legacy ldap realm returns 500 instead of 401
In-Reply-To: <JIRA.12674305.1486019615000@Atlassian.JIRA>
References: <JIRA.12674305.1486019615000@Atlassian.JIRA>
	<JIRA.12674305.1486019615324@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674305.1486019615000.45490.1486019640231@Atlassian.JIRA>

Ondrej Lukas created WFCORE-2257:
------------------------------------

             Summary: Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
                 Key: WFCORE-2257
                 URL: https://issues.jboss.org/browse/WFCORE-2257
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from EAP 7.0.x where status code 401 is returned.

This issue can be related to JBEAP-8106 (500 return for nonexistent user in legacy ldap security realm).

[~dlofthouse] should it be handled as blocker due to regression or is this change intended and we should just cover this change only in release notes?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:15:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 02:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2258) 500 return for nonexistent
 user in legacy ldap security realm
In-Reply-To: <JIRA.12674306.1486019644000@Atlassian.JIRA>
References: <JIRA.12674306.1486019644000@Atlassian.JIRA>
	<JIRA.12674306.1486019644097@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674306.1486019644000.45496.1486019700350@Atlassian.JIRA>

Martin Choma created WFCORE-2258:
------------------------------------

             Summary: 500 return for nonexistent user in legacy ldap security realm
                 Key: WFCORE-2258
                 URL: https://issues.jboss.org/browse/WFCORE-2258
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to EAP 7.0, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.

{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code} 




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:16:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 02:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2258) 500 return for nonexistent
 user in legacy ldap security realm
In-Reply-To: <JIRA.12674306.1486019644000@Atlassian.JIRA>
References: <JIRA.12674306.1486019644000@Atlassian.JIRA>
	<JIRA.12674306.1486019644000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674306.1486019644000.45505.1486019760542@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFCORE-2258:
---------------------------------
    Description: 
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.

{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code} 


  was:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to EAP 7.0, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.

{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code} 




> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
>                 Key: WFCORE-2258
>                 URL: https://issues.jboss.org/browse/WFCORE-2258
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: eap71_alpha, regression
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code} 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:16:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 2 Feb 2017 02:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2257) Missing username in LDAP
 entry for legacy ldap realm returns 500 instead of 401
In-Reply-To: <JIRA.12674305.1486019615000@Atlassian.JIRA>
References: <JIRA.12674305.1486019615000@Atlassian.JIRA>
	<JIRA.12674305.1486019615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674305.1486019615000.45511.1486019760830@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFCORE-2257:
---------------------------------
    Description: 
In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from WildFly 10 where status code 401 is returned.

This issue can be related to WFCORE-2258 (500 return for nonexistent user in legacy ldap security realm).

  was:
In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from EAP 7.0.x where status code 401 is returned.

This issue can be related to JBEAP-8106 (500 return for nonexistent user in legacy ldap security realm).

[~dlofthouse] should it be handled as blocker due to regression or is this change intended and we should just cover this change only in release notes?



> Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-2257
>                 URL: https://issues.jboss.org/browse/WFCORE-2257
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from WildFly 10 where status code 401 is returned.
> This issue can be related to WFCORE-2258 (500 return for nonexistent user in legacy ldap security realm).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:16:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 02:16:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2258) 500 return for nonexistent
 user in legacy ldap security realm
In-Reply-To: <JIRA.12674306.1486019644000@Atlassian.JIRA>
References: <JIRA.12674306.1486019644000@Atlassian.JIRA>
	<JIRA.12674306.1486019644000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674306.1486019644000.45517.1486019761118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFCORE-2258:
---------------------------------
    Description: 
In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.

{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code} 


  was:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.

{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code} 




> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
>                 Key: WFCORE-2258
>                 URL: https://issues.jboss.org/browse/WFCORE-2258
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: eap71_alpha, regression
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code} 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:17:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 02:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2258) 500 return for nonexistent
 user in legacy ldap security realm
In-Reply-To: <JIRA.12674306.1486019644000@Atlassian.JIRA>
References: <JIRA.12674306.1486019644000@Atlassian.JIRA>
	<JIRA.12674306.1486019644000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674306.1486019644000.45523.1486019820258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFCORE-2258:
---------------------------------
    Labels: regression  (was: eap71_alpha regression)


> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
>                 Key: WFCORE-2258
>                 URL: https://issues.jboss.org/browse/WFCORE-2258
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: regression
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code} 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 02:24:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 2 Feb 2017 02:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7920) There isn't possibility
 disable create CS file from scratch
In-Reply-To: <JIRA.12672203.1484895693000@Atlassian.JIRA>
References: <JIRA.12672203.1484895693000@Atlassian.JIRA>
	<JIRA.12672203.1484895693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672203.1484895693000.45546.1486020240336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek updated WFLY-7920:
-------------------------------
    Description: 
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.

  was:There isn't possibility to disable create CS file from scratch.



> There isn't possibility disable create CS file from scratch
> -----------------------------------------------------------
>
>                 Key: WFLY-7920
>                 URL: https://issues.jboss.org/browse/WFLY-7920
>             Project: WildFly
>          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  Thu Feb  2 02:26:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Thu, 2 Feb 2017 02:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-901) Credential Store doesn't
 support set create.storage true/false
In-Reply-To: <JIRA.12673556.1485765414000@Atlassian.JIRA>
References: <JIRA.12673556.1485765414000@Atlassian.JIRA>
	<JIRA.12673556.1485765414000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673556.1485765414000.45566.1486020360533@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek closed ELY-901.
----------------------------
    Resolution: Duplicate Issue


> Credential Store doesn't support set create.storage true/false
> --------------------------------------------------------------
>
>                 Key: ELY-901
>                 URL: https://issues.jboss.org/browse/ELY-901
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Assignee: Peter Skopek
>
> Credential Store doesn't support set create.storage true/false.
> 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  Thu Feb  2 04:15:00 2017
From: issues at jboss.org (Lei Yu (JIRA))
Date: Thu, 2 Feb 2017 04:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6573) Allow Vault encrypted strings
 to be updated without a restart
In-Reply-To: <JIRA.12617495.1461882442000@Atlassian.JIRA>
References: <JIRA.12617495.1461882442000@Atlassian.JIRA>
	<JIRA.12617495.1461882442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12617495.1461882442000.46138.1486026900602@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357259#comment-13357259 ] 

Lei Yu commented on WFLY-6573:
------------------------------

Customer Allianz Managed Operations & Services SE would like this feature to be implemented.

> Allow Vault encrypted strings to be updated without a restart
> -------------------------------------------------------------
>
>                 Key: WFLY-6573
>                 URL: https://issues.jboss.org/browse/WFLY-6573
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Darran Lofthouse
>
> When a new vault string is created the affected servers in the domain have to be restarted before the encrypted value is applied. This makes it difficult to test a new configuration in CLI.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 04:32:00 2017
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Thu, 2 Feb 2017 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2259) Setting JBOSS_MODULEPATH is
 lost for second start of embed-server
In-Reply-To: <JIRA.12674323.1486027896000@Atlassian.JIRA>
References: <JIRA.12674323.1486027896000@Atlassian.JIRA>
	<JIRA.12674323.1486027896678@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674323.1486027896000.46237.1486027920199@Atlassian.JIRA>

Panagiotis Sotiropoulos created WFCORE-2259:
-----------------------------------------------

             Summary: Setting JBOSS_MODULEPATH is lost for second start of embed-server
                 Key: WFCORE-2259
                 URL: https://issues.jboss.org/browse/WFCORE-2259
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI, Server
            Reporter: Panagiotis Sotiropoulos
            Assignee: Brian Stansberry
            Priority: Critical
             Fix For: 3.0.0.Alpha23


When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
The subsequent `embed-server` call results in error:
{code}
Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
{code}

Using the  {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#define_an_external_jboss_eap_module_directory



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 04:32:00 2017
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Thu, 2 Feb 2017 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2259) Setting JBOSS_MODULEPATH is
 lost for second start of embed-server
In-Reply-To: <JIRA.12674323.1486027897000@Atlassian.JIRA>
References: <JIRA.12674323.1486027897000@Atlassian.JIRA>
	<JIRA.12674323.1486027897000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674323.1486027897000.46242.1486027920395@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos updated WFCORE-2259:
--------------------------------------------
    Fix Version/s:     (was: 3.0.0.Alpha23)


> Setting JBOSS_MODULEPATH is lost for second start of embed-server
> -----------------------------------------------------------------
>
>                 Key: WFCORE-2259
>                 URL: https://issues.jboss.org/browse/WFCORE-2259
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Server
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
> The subsequent `embed-server` call results in error:
> {code}
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
> {code}
> Using the  {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#define_an_external_jboss_eap_module_directory



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 04:34:00 2017
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Thu, 2 Feb 2017 04:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2259) Setting JBOSS_MODULEPATH is
 lost for second start of embed-server
In-Reply-To: <JIRA.12674323.1486027897000@Atlassian.JIRA>
References: <JIRA.12674323.1486027897000@Atlassian.JIRA>
	<JIRA.12674323.1486027897000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674323.1486027897000.46257.1486028040511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos closed WFCORE-2259.
-------------------------------------------
    Resolution: Duplicate Issue


> Setting JBOSS_MODULEPATH is lost for second start of embed-server
> -----------------------------------------------------------------
>
>                 Key: WFCORE-2259
>                 URL: https://issues.jboss.org/browse/WFCORE-2259
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Server
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> When {{embed-server}} command is used more times in the CLI and a custom {{JBOSS_MODULEPATH}} is configured, then only the first server start uses the correct module path.
> The subsequent `embed-server` call results in error:
> {code}
> Cannot start embedded server: WFLYEMB0022: Cannot invoke 'start' on embedded process: WFLYSRV0118: Determined modules directory does not exist: /tmp/jboss-eap-7.0-no-modules/modules
> {code}
> Using the  {{JBOSS_MODULEPATH}} environment variable is documented in https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/7.0/single/configuration-guide/#define_an_external_jboss_eap_module_directory



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 04:39:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 2 Feb 2017 04:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1425) QueryCepFireUntilHaltTest
 often hangs during execution
In-Reply-To: <JIRA.12674330.1486028298000@Atlassian.JIRA>
References: <JIRA.12674330.1486028298000@Atlassian.JIRA>
	<JIRA.12674330.1486028298073@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674330.1486028298000.46321.1486028340319@Atlassian.JIRA>

Petr ?irok? created DROOLS-1425:
-----------------------------------

             Summary: QueryCepFireUntilHaltTest often hangs during execution
                 Key: DROOLS-1425
                 URL: https://issues.jboss.org/browse/DROOLS-1425
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Petr ?irok?
            Assignee: Mario Fusco
         Attachments: QueryCepFireUntilHaltTest-thread-dump.txt

The {{QueryCepFireUntilHaltTest}} recently started to hang the build quite often. It does use specific timeout, but either the timeout it too high (so the build timeouts anyway) or jUnit is not able to kill the test after the timeout passes. Based on the threaddump taken during the build, there seems to be a deadlock between two threads (see the attachment).





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb  2 04:39:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Thu, 2 Feb 2017 04:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1425) QueryCepFireUntilHaltTest
 often hangs during execution
In-Reply-To: <JIRA.12674330.1486028298000@Atlassian.JIRA>
References: <JIRA.12674330.1486028298000@Atlassian.JIRA>
	<JIRA.12674330.1486028298000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674330.1486028298000.46324.1486028340424@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? updated DROOLS-1425:
--------------------------------
    Attachment: QueryCepFireUntilHaltTest-thread-dump.txt


> QueryCepFireUntilHaltTest often hangs during execution
> ------------------------------------------------------
>
>                 Key: DROOLS-1425
>                 URL: https://issues.jboss.org/browse/DROOLS-1425
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Petr ?irok?
>            Assignee: Mario Fusco
>         Attachments: QueryCepFireUntilHaltTest-thread-dump.txt
>
>
> The {{QueryCepFireUntilHaltTest}} recently started to hang the build quite often. It does use specific timeout, but either the timeout it too high (so the build timeouts anyway) or jUnit is not able to kill the test after the timeout passes. Based on the threaddump taken during the build, there seems to be a deadlock between two threads (see the attachment).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb  2 05:13:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 2 Feb 2017 05:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-907) LdapRealm - different
 principal/credential for referrals
In-Reply-To: <JIRA.12674341.1486030362000@Atlassian.JIRA>
References: <JIRA.12674341.1486030362000@Atlassian.JIRA>
	<JIRA.12674341.1486030362873@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674341.1486030362000.46596.1486030380288@Atlassian.JIRA>

Jan Kalina created ELY-907:
------------------------------

             Summary: LdapRealm - different principal/credential for referrals
                 Key: ELY-907
                 URL: https://issues.jboss.org/browse/ELY-907
             Project: WildFly Elytron
          Issue Type: Enhancement
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Minor


When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.

This can be done using AuthenticationContext by following way:
http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 05:14:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 2 Feb 2017 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-907) LdapRealm - different
 principal/credential for referrals
In-Reply-To: <JIRA.12674341.1486030363000@Atlassian.JIRA>
References: <JIRA.12674341.1486030363000@Atlassian.JIRA>
	<JIRA.12674341.1486030363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674341.1486030363000.46608.1486030440317@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-907:
---------------------------
    Description: 
When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.

This can be done when using AuthenticationContext.

Note: how to pass different credentials into referred DirContext:
http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)

  was:
When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.

This can be done using AuthenticationContext by following way:
http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



> LdapRealm - different principal/credential for referrals
> --------------------------------------------------------
>
>                 Key: ELY-907
>                 URL: https://issues.jboss.org/browse/ELY-907
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Minor
>
> When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.
> This can be done when using AuthenticationContext.
> Note: how to pass different credentials into referred DirContext:
> http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 06:02:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Feb 2017 06:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6573) Allow Vault encrypted strings
 to be updated without a restart
In-Reply-To: <JIRA.12617495.1461882442000@Atlassian.JIRA>
References: <JIRA.12617495.1461882442000@Atlassian.JIRA>
	<JIRA.12617495.1461882442000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12617495.1461882442000.46991.1486033321155@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-6573:
-----------------------------------
    Comment: was deleted

(was: Customer Allianz Managed Operations & Services SE would like this feature to be implemented.)


> Allow Vault encrypted strings to be updated without a restart
> -------------------------------------------------------------
>
>                 Key: WFLY-6573
>                 URL: https://issues.jboss.org/browse/WFLY-6573
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Darran Lofthouse
>
> When a new vault string is created the affected servers in the domain have to be restarted before the encrypted value is applied. This makes it difficult to test a new configuration in CLI.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 07:23:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 2 Feb 2017 07:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8011) Remove Ignored tests from
 EarModulesPPTestCase
In-Reply-To: <JIRA.12674382.1486038140000@Atlassian.JIRA>
References: <JIRA.12674382.1486038140000@Atlassian.JIRA>
	<JIRA.12674382.1486038140215@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674382.1486038140000.47566.1486038180492@Atlassian.JIRA>

Josef Cacek created WFLY-8011:
---------------------------------

             Summary: Remove Ignored tests from EarModulesPPTestCase
                 Key: WFLY-8011
                 URL: https://issues.jboss.org/browse/WFLY-8011
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Josef Cacek


The related issue JBEAP-411/WFLY-4886 was rejected so the tests don't check expected behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 07:23:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 2 Feb 2017 07:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8011) Remove Ignored tests from
 EarModulesPPTestCase
In-Reply-To: <JIRA.12674382.1486038140000@Atlassian.JIRA>
References: <JIRA.12674382.1486038140000@Atlassian.JIRA>
	<JIRA.12674382.1486038140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674382.1486038140000.47568.1486038180590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-8011:
---------------------------------

    Assignee: Josef Cacek


> Remove Ignored tests from EarModulesPPTestCase
> ----------------------------------------------
>
>                 Key: WFLY-8011
>                 URL: https://issues.jboss.org/browse/WFLY-8011
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The related issue JBEAP-411/WFLY-4886 was rejected so the tests don't check expected behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 07:37:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 2 Feb 2017 07:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-908) Fix
	LegacyPropertiesSecurityRealmTest
In-Reply-To: <JIRA.12674384.1486038994000@Atlassian.JIRA>
References: <JIRA.12674384.1486038994000@Atlassian.JIRA>
	<JIRA.12674384.1486038994061@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674384.1486038994000.47657.1486039020240@Atlassian.JIRA>

Ondrej Lukas created ELY-908:
--------------------------------

             Summary: Fix LegacyPropertiesSecurityRealmTest
                 Key: ELY-908
                 URL: https://issues.jboss.org/browse/ELY-908
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
    Affects Versions: 1.1.0.Beta21
            Reporter: Ondrej Lukas
            Assignee: Ondrej Lukas
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 07:44:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 2 Feb 2017 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-908) Fix
	LegacyPropertiesSecurityRealmTest
In-Reply-To: <JIRA.12674384.1486038994000@Atlassian.JIRA>
References: <JIRA.12674384.1486038994000@Atlassian.JIRA>
	<JIRA.12674384.1486038994000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674384.1486038994000.47717.1486039440225@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-908:
-----------------------------
    Description: {{specialchars.properties}} uses wrong encoding which results to test failures.


> Fix LegacyPropertiesSecurityRealmTest
> -------------------------------------
>
>                 Key: ELY-908
>                 URL: https://issues.jboss.org/browse/ELY-908
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Ondrej Lukas
>            Priority: Minor
>
> {{specialchars.properties}} uses wrong encoding which results to test failures.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 07:45:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 2 Feb 2017 07:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8011) Remove Ignored tests from
 EarModulesPPTestCase
In-Reply-To: <JIRA.12674382.1486038140000@Atlassian.JIRA>
References: <JIRA.12674382.1486038140000@Atlassian.JIRA>
	<JIRA.12674382.1486038140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674382.1486038140000.47729.1486039501013@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-8011:
------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9589


> Remove Ignored tests from EarModulesPPTestCase
> ----------------------------------------------
>
>                 Key: WFLY-8011
>                 URL: https://issues.jboss.org/browse/WFLY-8011
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The related issue JBEAP-411/WFLY-4886 was rejected so the tests don't check expected behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 08:52:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 08:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8012) Elytron
 kerberos-security-factory debug attribute type
In-Reply-To: <JIRA.12674408.1486043508000@Atlassian.JIRA>
References: <JIRA.12674408.1486043508000@Atlassian.JIRA>
	<JIRA.12674408.1486043508774@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674408.1486043508000.48416.1486043521254@Atlassian.JIRA>

Martin Choma created WFLY-8012:
----------------------------------

             Summary: Elytron kerberos-security-factory debug attribute type
                 Key: WFLY-8012
                 URL: https://issues.jboss.org/browse/WFLY-8012
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


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}
                <xs:attribute name="debug" type="xs:boolean" default="false">
                    <xs:annotation>
                        <xs:documentation>
                            Should the JAAS step of obtaining the credential have debug logging enabled.
                        </xs:documentation>
                    </xs:annotation>
                </xs:attribute>
{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 08:53:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 2 Feb 2017 08:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8012) Elytron
 kerberos-security-factory debug attribute type
In-Reply-To: <JIRA.12674408.1486043509000@Atlassian.JIRA>
References: <JIRA.12674408.1486043509000@Atlassian.JIRA>
	<JIRA.12674408.1486043509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674408.1486043509000.48431.1486043580837@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8012:
-------------------------------
    Labels: user_experience  (was: UserExperience)


> Elytron kerberos-security-factory debug attribute type
> ------------------------------------------------------
>
>                 Key: WFLY-8012
>                 URL: https://issues.jboss.org/browse/WFLY-8012
>             Project: WildFly
>          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}
>                 <xs:attribute name="debug" type="xs:boolean" default="false">
>                     <xs:annotation>
>                         <xs:documentation>
>                             Should the JAAS step of obtaining the credential have debug logging enabled.
>                         </xs:documentation>
>                     </xs:annotation>
>                 </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 09:17:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 2 Feb 2017 09:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1418) Binding of List stored in
 Map doesn't work in special case
In-Reply-To: <JIRA.12673228.1485444407000@Atlassian.JIRA>
References: <JIRA.12673228.1485444407000@Atlassian.JIRA>
	<JIRA.12673228.1485444407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673228.1485444407000.48949.1486045020783@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1418.
---------------------------------
    Fix Version/s: 7.0.0.CR1
       Resolution: Done


Fixed on mvel with this commit https://github.com/mvel/mvel/commit/7f247cd6018cbb9d6a5b5c07e3b1ba7e770cb205

> Binding of List stored in Map doesn't work in special case
> ----------------------------------------------------------
>
>                 Key: DROOLS-1418
>                 URL: https://issues.jboss.org/browse/DROOLS-1418
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta5
>            Reporter: Jozef Marko
>            Assignee: Mario Fusco
>              Labels: dtable_testday_preparation, reported-by-qe
>             Fix For: 7.0.0.CR1
>
>         Attachments: reproducer.zip
>
>
> User has possibility to bind a List stored as item of a Map in his rule. However this dosn't work in one special case. For more details see the steps to reproduce.
> This issue was discussed with [~tari_manga] and he also provided the workaround used in reproducer. Thanks.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 09:22:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 2 Feb 2017 09:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-909) Elytron ldap-realm does not
 handle loops in referrals
In-Reply-To: <JIRA.12672644.1485244863000@Atlassian.JIRA>
References: <JIRA.12672644.1485244863000@Atlassian.JIRA>
	<JIRA.12672644.1485244863000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672644.1485244863000.48988.1486045321091@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-7946 to ELY-909:
--------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-909  (was: WFLY-7946)
          Component/s: Realms
                           (was: Security)
    Affects Version/s: 1.1.0.Beta21
                           (was: 11.0.0.Alpha1)


> Elytron ldap-realm does not handle loops in referrals
> -----------------------------------------------------
>
>                 Key: ELY-909
>                 URL: https://issues.jboss.org/browse/ELY-909
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 09:35:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Feb 2017 09:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2260) Validate presence of
 required attributes in PersistentResourceXmlParser/Description
In-Reply-To: <JIRA.12674493.1486046034000@Atlassian.JIRA>
References: <JIRA.12674493.1486046034000@Atlassian.JIRA>
	<JIRA.12674493.1486046034000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674493.1486046034000.49132.1486046100230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-8634 to WFCORE-2260:
-------------------------------------------------

           Project: WildFly Core  (was: JBoss Enterprise Application Platform)
               Key: WFCORE-2260  (was: JBEAP-8634)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: Domain Management
                        (was: Domain Management)
    Target Release:   (was: 7.1.0.GA)


> Validate presence of required attributes in PersistentResourceXmlParser/Description
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2260
>                 URL: https://issues.jboss.org/browse/WFCORE-2260
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>
> One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
> See JBEAP-8437 for an example of where that no longer happens.
> Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand.
> Things that generic support would need to understand:
> 1) Attributes with alternatives are not required if the alternative is set.
> 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
> Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
> This is NOT meant for WildFly Core 3.0.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 09:38:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Feb 2017 09:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2260) Validate presence of
 required attributes in PersistentResourceXmlParser/Description
In-Reply-To: <JIRA.12674493.1486046034000@Atlassian.JIRA>
References: <JIRA.12674493.1486046034000@Atlassian.JIRA>
	<JIRA.12674493.1486046034000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674493.1486046034000.49151.1486046280493@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2260:
-------------------------------------
    Description: 
One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.

See JBEAP-8437 for an example of where that no longer happens.

Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. (Of course being generic is a great advantage once it's done right since it gets applied consistently.)

Things that generic support would need to understand:

1) Attributes with alternatives are not required if the alternative is set.
2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.

Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)


This is NOT meant for WildFly Core 3.0.

  was:
One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.

See JBEAP-8437 for an example of where that no longer happens.

Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand.

Things that generic support would need to understand:

1) Attributes with alternatives are not required if the alternative is set.
2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.

Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)


This is NOT meant for WildFly Core 3.0.



> Validate presence of required attributes in PersistentResourceXmlParser/Description
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2260
>                 URL: https://issues.jboss.org/browse/WFCORE-2260
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>
> One disadvantage of moving away from hand coded parsers to PersistentResourceXmlParser/Description is the hand coded ones often had a bit of logic to confirm that all expected attributes were set and fail with XmlStreamException if not. The benefit of that vs failing in boot operation execution is the indication of where in the xml the problem is and the integration with VDX.
> See JBEAP-8437 for an example of where that no longer happens.
> Adding this kind of thing to PersistentResourceXmlParser/Description is a bit tricky since it's generic while the hand coded stuff could just be applied where it was easy for the author to understand. (Of course being generic is a great advantage once it's done right since it gets applied consistently.)
> Things that generic support would need to understand:
> 1) Attributes with alternatives are not required if the alternative is set.
> 2) Whether persistence is all via xml attributes or whether elements are involved. IOW when should the check that all required things are set be performed? If all persistence is to xml attributes then it should be done once the start element is parsed, before child elements. But if child elements are involved, then this needs to be deferred. Or I guess repeated, with logic that recognizes it's possible a required attribute that is persisted as an xml attribute may have an alternative that is persisted as an element.
> Speaking more generally, Jeff Mesnil had the brainstorming thought that beyond specific logic for this it may be possible for PersistentResourceXmlParser/Description to do validation against schema. Plenty of issues to consider there, including how to deal with expressions. (It would be great if it were easy to ask an xml validator to just validate structure, but ignore whether attribute values match the schema rules. That would avoid the problem with expressions. We already validate all the attribute values.)
> This is NOT meant for WildFly Core 3.0.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:20:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 2 Feb 2017 10:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7912) It's not possible to change
 election-policy of singleton-policy
In-Reply-To: <JIRA.12671971.1484818721000@Atlassian.JIRA>
References: <JIRA.12671971.1484818721000@Atlassian.JIRA>
	<JIRA.12671971.1484818721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671971.1484818721000.49541.1486048800701@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357677#comment-13357677 ] 

Tomas Hofman commented on WFLY-7912:
------------------------------------

[~pferraro] I think this should be reopened. Changing from simple election policy to random is working as you described, but changing from random back to simple is not:

{code}
[standalone at localhost:9990 /] /subsystem=singleton/singleton-policy=default/election-policy=simple:add {allow-resource-service-restart=true}
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered",
    "rolled-back" => true
}
{code}

The random-election-policy is not recognized as a required singleton sibling in AddStepHandler and isn't removed.

Also, this approach doesn't go along with Web Console.

> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
>                 Key: WFLY-7912
>                 URL: https://issues.jboss.org/browse/WFLY-7912
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone at localhost:9990 /] batch 
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone at localhost:9990 / #] run-batch 
> {code}
> results in
> {code}
> 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-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea24e0206bb1



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:21:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 2 Feb 2017 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7912) It's not possible to change
 election-policy of singleton-policy
In-Reply-To: <JIRA.12671971.1484818721000@Atlassian.JIRA>
References: <JIRA.12671971.1484818721000@Atlassian.JIRA>
	<JIRA.12671971.1484818721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671971.1484818721000.49547.1486048860266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reopened WFLY-7912:
--------------------------------


> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
>                 Key: WFLY-7912
>                 URL: https://issues.jboss.org/browse/WFLY-7912
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone at localhost:9990 /] batch 
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone at localhost:9990 / #] run-batch 
> {code}
> results in
> {code}
> 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-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea24e0206bb1



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Feb 2017 10:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2261) Where the server module
 depends on protocol it needs to include META-INF
In-Reply-To: <JIRA.12674593.1486050318000@Atlassian.JIRA>
References: <JIRA.12674593.1486050318000@Atlassian.JIRA>
	<JIRA.12674593.1486050318943@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674593.1486050318000.50086.1486050360686@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2261:
----------------------------------------

             Summary: Where the server module depends on protocol it needs to include META-INF
                 Key: WFCORE-2261
                 URL: https://issues.jboss.org/browse/WFCORE-2261
             Project: WildFly Core
          Issue Type: Task
          Components: Server
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:46:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 10:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7912) It's not possible to change
 election-policy of singleton-policy
In-Reply-To: <JIRA.12671971.1484818721000@Atlassian.JIRA>
References: <JIRA.12671971.1484818721000@Atlassian.JIRA>
	<JIRA.12671971.1484818721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671971.1484818721000.50083.1486050360619@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-7912.
------------------------------
    Resolution: Rejected


[~thofman] You cannot just add the simple policy without removing the existing random policy.  Remember, the only operations that are implicit are the election-policy=simple:add or remove.  Therefore, to revert from the random policy back to the default (i.e. simple) policy, you would use the following command:
{noformat}
/subsystem=singleton/singleton-policy=default/election-policy=random:remove(){allow-resource-service-restart=true}
{noformat}

This is effectively a short cut, since the election-policy=simple:add() is implied (i.e. optional).

> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
>                 Key: WFLY-7912
>                 URL: https://issues.jboss.org/browse/WFLY-7912
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone at localhost:9990 /] batch 
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone at localhost:9990 / #] run-batch 
> {code}
> results in
> {code}
> 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-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea24e0206bb1



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:53:00 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Thu, 2 Feb 2017 10:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050724000@Atlassian.JIRA>
References: <JIRA.12674595.1486050724000@Atlassian.JIRA>
	<JIRA.12674595.1486050724812@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050724000.50148.1486050780261@Atlassian.JIRA>

Tiago Matias created WFLY-8013:
----------------------------------

             Summary: Out of memory exception after a number of remote deploys
                 Key: WFLY-8013
                 URL: https://issues.jboss.org/browse/WFLY-8013
             Project: WildFly
          Issue Type: Enhancement
          Components: Server
    Affects Versions: 10.1.0.Final
         Environment: Server: Ubuntu 16.04.1 LTS x64

Startup arguments:
{{
 java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0}}
            Reporter: Tiago Matias
            Assignee: Jason Greene
            Priority: Minor


Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.

Full error log of maven.
{{
[INFO] Authenticating against security realm: ManagementRealm
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.630 s
[INFO] Finished at: 2017-02-02T15:38:04+00:00
[INFO] Final Memory: 22M/290M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
[ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
vailable dependencies" => undefined}}}}}





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:53:00 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Thu, 2 Feb 2017 10:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050725000@Atlassian.JIRA>
References: <JIRA.12674595.1486050725000@Atlassian.JIRA>
	<JIRA.12674595.1486050725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050725000.50151.1486050780358@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago Matias updated WFLY-8013:
-------------------------------
    Environment: 
Server: Ubuntu 16.04.1 LTS x64

Startup arguments:


 java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0

  was:
Server: Ubuntu 16.04.1 LTS x64

Startup arguments:
{{
 java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0}}



> Out of memory exception after a number of remote deploys
> --------------------------------------------------------
>
>                 Key: WFLY-8013
>                 URL: https://issues.jboss.org/browse/WFLY-8013
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 10.1.0.Final
>         Environment: Server: Ubuntu 16.04.1 LTS x64
> Startup arguments:
>  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0
>            Reporter: Tiago Matias
>            Assignee: Jason Greene
>            Priority: Minor
>
> Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.
> Full error log of maven.
> {{
> [INFO] Authenticating against security realm: ManagementRealm
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 47.630 s
> [INFO] Finished at: 2017-02-02T15:38:04+00:00
> [INFO] Final Memory: 22M/290M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
> . Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
> backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
> [ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
> vailable dependencies" => undefined}}}}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:54:00 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Thu, 2 Feb 2017 10:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050725000@Atlassian.JIRA>
References: <JIRA.12674595.1486050725000@Atlassian.JIRA>
	<JIRA.12674595.1486050725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050725000.50160.1486050840562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago Matias updated WFLY-8013:
-------------------------------
    Description: 
Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.

*Full error log of maven.*
{quote}
[INFO] Authenticating against security realm: ManagementRealm
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.630 s
[INFO] Finished at: 2017-02-02T15:38:04+00:00
[INFO] Final Memory: 22M/290M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
[ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
vailable dependencies" => undefined}}}


{quote}

  was:
Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.

Full error log of maven.
{{
[INFO] Authenticating against security realm: ManagementRealm
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.630 s
[INFO] Finished at: 2017-02-02T15:38:04+00:00
[INFO] Final Memory: 22M/290M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
[ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
vailable dependencies" => undefined}}}}}





> Out of memory exception after a number of remote deploys
> --------------------------------------------------------
>
>                 Key: WFLY-8013
>                 URL: https://issues.jboss.org/browse/WFLY-8013
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 10.1.0.Final
>         Environment: Server: Ubuntu 16.04.1 LTS x64
> Startup arguments:
>  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0
>            Reporter: Tiago Matias
>            Assignee: Jason Greene
>            Priority: Minor
>
> Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.
> *Full error log of maven.*
> {quote}
> [INFO] Authenticating against security realm: ManagementRealm
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 47.630 s
> [INFO] Finished at: 2017-02-02T15:38:04+00:00
> [INFO] Final Memory: 22M/290M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
> . Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
> backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
> [ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
> vailable dependencies" => undefined}}}
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 10:55:00 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Thu, 2 Feb 2017 10:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050725000@Atlassian.JIRA>
References: <JIRA.12674595.1486050725000@Atlassian.JIRA>
	<JIRA.12674595.1486050725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050725000.50179.1486050900655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago Matias updated WFLY-8013:
-------------------------------
    Environment: 
Server: Ubuntu 16.04.1 LTS x64
bq. 
bq. Startup arguments:
bq. 
bq. 
bq.  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0

  was:
Server: Ubuntu 16.04.1 LTS x64

Startup arguments:


 java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0



> Out of memory exception after a number of remote deploys
> --------------------------------------------------------
>
>                 Key: WFLY-8013
>                 URL: https://issues.jboss.org/browse/WFLY-8013
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 10.1.0.Final
>         Environment: Server: Ubuntu 16.04.1 LTS x64
> bq. 
> bq. Startup arguments:
> bq. 
> bq. 
> bq.  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0
>            Reporter: Tiago Matias
>            Assignee: Jason Greene
>            Priority: Minor
>
> Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.
> *Full error log of maven.*
> {quote}
> [INFO] Authenticating against security realm: ManagementRealm
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 47.630 s
> [INFO] Finished at: 2017-02-02T15:38:04+00:00
> [INFO] Final Memory: 22M/290M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
> . Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
> backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
> [ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
> vailable dependencies" => undefined}}}
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:03:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 2 Feb 2017 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7912) It's not possible to change
 election-policy of singleton-policy
In-Reply-To: <JIRA.12671971.1484818721000@Atlassian.JIRA>
References: <JIRA.12671971.1484818721000@Atlassian.JIRA>
	<JIRA.12671971.1484818721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671971.1484818721000.50242.1486051380201@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357764#comment-13357764 ] 

Tomas Hofman commented on WFLY-7912:
------------------------------------

Right, that works, thanks for explanation.

> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
>                 Key: WFLY-7912
>                 URL: https://issues.jboss.org/browse/WFLY-7912
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone at localhost:9990 /] batch 
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone at localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone at localhost:9990 / #] run-batch 
> {code}
> results in
> {code}
> 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-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea24e0206bb1



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:18:01 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Thu, 2 Feb 2017 11:18:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244015@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.50370.1486052281063@Atlassian.JIRA>

Michal Petrov created WFLY-8014:
-----------------------------------

             Summary: Remote store cannot be added to a cache via CLI
                 Key: WFLY-8014
                 URL: https://issues.jboss.org/browse/WFLY-8014
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 11.0.0.Alpha1
            Reporter: Michal Petrov
            Assignee: Paul Ferraro


It is not possible to add remote store to a new cache:
{quote}
/subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
    "rolled-back" => true
}
{quote}

However it is possible to add a file store:
{{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:27:00 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Thu, 2 Feb 2017 11:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.50470.1486052820654@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357792#comment-13357792 ] 

Michal Petrov commented on WFLY-8014:
-------------------------------------

This might be two different issues. From what I'm able to tell the file store is not installed through {{ResourceServiceHandler.installServices()}} and somehow skips the check for an existing service. Even then the problem is that store=none is treated as an existing service when it's meant to be overwritten.

> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:34:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.50541.1486053240445@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-8014.
------------------------------
    Resolution: Rejected


You must use the allow-resource-service-restart=true invocation flag, since the addition of the file cache-store implies the removal of the existing store=none resource.
e.g.
{noformat}
/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add(){allow-resource-service-restart=true}
{noformat}

Note that the above command automatically removes the existing default store=none resource.  This one liner is equivalent to the following:
{noformat}
batch
/subsystem=infinispan/cache-container=web/local-cache=myCache/store=none:remove(){allow-resource-service-restart=true}
/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add()
run-batch
{noformat}

> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:38:01 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 2 Feb 2017 11:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-662) Autopublish drools-website,
 optaplanner-website and jbpm-website through travis
In-Reply-To: <JIRA.12558919.1418048641000@Atlassian.JIRA>
References: <JIRA.12558919.1418048641000@Atlassian.JIRA>
	<JIRA.12558919.1418048641000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558919.1418048641000.50573.1486053481062@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357804#comment-13357804 ] 

Michael Biarnes Kiefer commented on DROOLS-662:
-----------------------------------------------

done:
see https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Websites/ 
it was tested and it works.
When a commit was pushed to one of the websites, it will automatically  run one of these three jobs which
creates a Docker images based on the Dockerfile in the respective web in _dockerPublisher, runs a Docker Container which does a rake setup, rake clean build and rake publish.

> Autopublish drools-website, optaplanner-website and jbpm-website through travis
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-662
>                 URL: https://issues.jboss.org/browse/DROOLS-662
>             Project: Drools
>          Issue Type: Task
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> The jboss-tools guys already auto publish their awestruct website. xcoulon on irc #awestruct told me how they do this at Devoxx. 
> Travis is like Jenkins, but works really well for ruby stuff (such as awestruct websites). It can publish our websites automatically if we push a commit. Here's how to set it up:
> - Add a .travis.yml file, look at this one for inspiration: https://github.com/jbosstools/jbosstools-website/blob/master/.travis.yml
> - Get a secret token to be able to publish a website on jboss.org filemanagement server. Then encrypt that secret token with Travis's public key (so only Travis can decrypt it). Write the encrypted secret token in the travis.yml file. Remove all knowledge of the actual secret token, so it can't leak.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:38:01 2017
From: issues at jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 2 Feb 2017 11:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-662) Autopublish drools-website,
 optaplanner-website and jbpm-website through travis
In-Reply-To: <JIRA.12558919.1418048641000@Atlassian.JIRA>
References: <JIRA.12558919.1418048641000@Atlassian.JIRA>
	<JIRA.12558919.1418048641000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12558919.1418048641000.50578.1486053481197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Biarnes Kiefer closed DROOLS-662.
-----------------------------------------
    Resolution: Done


> Autopublish drools-website, optaplanner-website and jbpm-website through travis
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-662
>                 URL: https://issues.jboss.org/browse/DROOLS-662
>             Project: Drools
>          Issue Type: Task
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> The jboss-tools guys already auto publish their awestruct website. xcoulon on irc #awestruct told me how they do this at Devoxx. 
> Travis is like Jenkins, but works really well for ruby stuff (such as awestruct websites). It can publish our websites automatically if we push a commit. Here's how to set it up:
> - Add a .travis.yml file, look at this one for inspiration: https://github.com/jbosstools/jbosstools-website/blob/master/.travis.yml
> - Get a secret token to be able to publish a website on jboss.org filemanagement server. Then encrypt that secret token with Travis's public key (so only Travis can decrypt it). Write the encrypted secret token in the travis.yml file. Remove all knowledge of the actual secret token, so it can't leak.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:46:00 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Thu, 2 Feb 2017 11:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.50668.1486053960859@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357816#comment-13357816 ] 

Michal Petrov commented on WFLY-8014:
-------------------------------------

[~pferraro] okay, but why is the flag needed for store=remote but not for store=file?

> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:49:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 2 Feb 2017 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1420) (int) ($p * 1_000.0) throws
 a misleading exception
In-Reply-To: <JIRA.12673443.1485531012000@Atlassian.JIRA>
References: <JIRA.12673443.1485531012000@Atlassian.JIRA>
	<JIRA.12673443.1485531012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673443.1485531012000.50683.1486054140472@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1420.
---------------------------------
    Fix Version/s: 7.0.0.CR1
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/d70058bb6ea7516a0054ef5063d94d173cda479f

> (int) ($p * 1_000.0) throws a misleading exception
> --------------------------------------------------
>
>                 Key: DROOLS-1420
>                 URL: https://issues.jboss.org/browse/DROOLS-1420
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta5
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.CR1
>
>
> This fails with *$p cannot be resolved to a variable*:
> {code}
> rule R when
>   Cheese($p : price)
> then
>   int b = (int) ($p * 1_000.0); // FAILS, because $p cannot be resolved ?!
> end
> {code}
> That error message is nonsense. It should just work. If it doesn't due to ECJ, it should say something like "cannot be cast".
> This works in java:
> {code}
>         int a = 42;
>         int b = ((int) (a * 1_000.0));
> {code}
> Removing the underscore fixes it:
> {code}
> rule R when
>   Cheese($p : price)
> then
>   int b = (int) ($p * 1000.0); // SUCCESS
> end
> {code}
> Regardless of an upstream ECJ problem (which should be reported if that's indeed the problem), the error message is wrong and send me on a wild goose hunt.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:51:01 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 2 Feb 2017 11:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8007) Replace WorkManager
 elytron-enabled atttribute by elytron-security-domain
In-Reply-To: <JIRA.12674108.1485947862000@Atlassian.JIRA>
References: <JIRA.12674108.1485947862000@Atlassian.JIRA>
	<JIRA.12674108.1485947862000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674108.1485947862000.50696.1486054261161@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13357819#comment-13357819 ] 

James Perkins commented on WFLY-8007:
-------------------------------------

[~flavia.rainone] I'm not sure if I'll have the time. I'm trying to get Arquillian to work with Elytron and I've got some days of PTO coming up. If I get done with the Arquillian stuff quickly I'll let you know though. I'm just currently having issues with it.

> Replace WorkManager elytron-enabled atttribute by elytron-security-domain
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8007
>                 URL: https://issues.jboss.org/browse/WFLY-8007
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: James Perkins
>
> Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 11:51:07 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 11:51:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8015) JGroups
 export-native-configuration management operation fails
In-Reply-To: <JIRA.12674610.1486054244000@Atlassian.JIRA>
References: <JIRA.12674610.1486054244000@Atlassian.JIRA>
	<JIRA.12674610.1486054244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674610.1486054244000.50731.1486054267925@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-8637 to WFLY-8015:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8015  (was: JBEAP-8637)
             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.DR11)


> JGroups export-native-configuration management operation fails
> --------------------------------------------------------------
>
>                 Key: WFLY-8015
>                 URL: https://issues.jboss.org/browse/WFLY-8015
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> [standalone at embedded /] /subsystem=jgroups/stack=udp:export-native-configuration()
> 11:40:20,261 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 2) WFLYCTL0013: Operation ("export-native-configuration") failed - address: ([
>     ("subsystem" => "jgroups"),
>     ("stack" => "udp")
> ]): 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.clustering.controller.Operations.getAttributeName(Operations.java:81)
> 	at org.jboss.as.clustering.controller.ExecutionHandler.executeRuntimeStep(ExecutionHandler.java:59)
> 	at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 	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$0(ModelControllerImpl.java:224)
> 	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:224)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:716)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:706)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:68)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:69)
> 	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:653)
> 	at org.jboss.as.cli.impl.CommandContextImpl.lambda$execute$1(CommandContextImpl.java:862)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:861)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:90)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:806)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:907)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:442)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'name' exists",
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 12:00:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Feb 2017 12:00:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2261) Where the server and host
 modules depends on protocol they need to include META-INF
In-Reply-To: <JIRA.12674593.1486050319000@Atlassian.JIRA>
References: <JIRA.12674593.1486050319000@Atlassian.JIRA>
	<JIRA.12674593.1486050319000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674593.1486050319000.50848.1486054802869@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2261:
-------------------------------------
    Summary: Where the server and host modules depends on protocol they need to include META-INF  (was: Where the server module depends on protocol it needs to include META-INF)


> Where the server and host modules depends on protocol they need to include META-INF
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2261
>                 URL: https://issues.jboss.org/browse/WFCORE-2261
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 12:06:01 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 12:06:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8015) JGroups
 export-native-configuration management operation fails
In-Reply-To: <JIRA.12674610.1486054244000@Atlassian.JIRA>
References: <JIRA.12674610.1486054244000@Atlassian.JIRA>
	<JIRA.12674610.1486054244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674610.1486054244000.51023.1486055161156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8015:
-------------------------------
    Description: 
{noformat}
[standalone at embedded /] /subsystem=jgroups/stack=udp:export-native-configuration()
11:40:20,261 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 2) WFLYCTL0013: Operation ("export-native-configuration") failed - address: ([
    ("subsystem" => "jgroups"),
    ("stack" => "udp")
]): 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.clustering.controller.Operations.getAttributeName(Operations.java:81)
	at org.jboss.as.clustering.controller.ExecutionHandler.executeRuntimeStep(ExecutionHandler.java:59)
	at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
	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$0(ModelControllerImpl.java:224)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:224)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:716)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:706)
	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:68)
	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:69)
	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:653)
	at org.jboss.as.cli.impl.CommandContextImpl.lambda$execute$1(CommandContextImpl.java:862)
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:861)
	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:90)
	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:806)
	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:907)
	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:442)
	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
	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)

{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'name' exists",
    "rolled-back" => true
}
{noformat}


  was:
[standalone at embedded /] /subsystem=jgroups/stack=udp:export-native-configuration()
11:40:20,261 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 2) WFLYCTL0013: Operation ("export-native-configuration") failed - address: ([
    ("subsystem" => "jgroups"),
    ("stack" => "udp")
]): 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.clustering.controller.Operations.getAttributeName(Operations.java:81)
	at org.jboss.as.clustering.controller.ExecutionHandler.executeRuntimeStep(ExecutionHandler.java:59)
	at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
	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$0(ModelControllerImpl.java:224)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:224)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:716)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:706)
	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:68)
	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:69)
	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:653)
	at org.jboss.as.cli.impl.CommandContextImpl.lambda$execute$1(CommandContextImpl.java:862)
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:861)
	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:90)
	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:806)
	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:907)
	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:442)
	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
	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)

{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'name' exists",
    "rolled-back" => true
}




> JGroups export-native-configuration management operation fails
> --------------------------------------------------------------
>
>                 Key: WFLY-8015
>                 URL: https://issues.jboss.org/browse/WFLY-8015
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> {noformat}
> [standalone at embedded /] /subsystem=jgroups/stack=udp:export-native-configuration()
> 11:40:20,261 ERROR [org.jboss.as.controller.management-operation] (AeshProcess: 2) WFLYCTL0013: Operation ("export-native-configuration") failed - address: ([
>     ("subsystem" => "jgroups"),
>     ("stack" => "udp")
> ]): 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.clustering.controller.Operations.getAttributeName(Operations.java:81)
> 	at org.jboss.as.clustering.controller.ExecutionHandler.executeRuntimeStep(ExecutionHandler.java:59)
> 	at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 	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$0(ModelControllerImpl.java:224)
> 	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:193)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:224)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:716)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:706)
> 	at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:68)
> 	at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:69)
> 	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:653)
> 	at org.jboss.as.cli.impl.CommandContextImpl.lambda$execute$1(CommandContextImpl.java:862)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:861)
> 	at org.jboss.as.cli.handlers.OperationRequestHandler.handle(OperationRequestHandler.java:90)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:806)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:907)
> 	at org.jboss.as.cli.impl.CommandContextImpl$2.execute(CommandContextImpl.java:442)
> 	at org.jboss.aesh.console.AeshProcess.run(AeshProcess.java:53)
> 	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)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'name' exists",
>     "rolled-back" => true
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 12:34:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Feb 2017 12:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2262) Merge Elytron invocation
 integration topic branch.
In-Reply-To: <JIRA.12674619.1486056781000@Atlassian.JIRA>
References: <JIRA.12674619.1486056781000@Atlassian.JIRA>
	<JIRA.12674619.1486056781817@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674619.1486056781000.51194.1486056840342@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2262:
----------------------------------------

             Summary: Merge Elytron invocation integration topic branch.
                 Key: WFCORE-2262
                 URL: https://issues.jboss.org/browse/WFCORE-2262
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 12:39:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 2 Feb 2017 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8016) Merge Elytron invocation
 integration topic branch.
In-Reply-To: <JIRA.12674620.1486057102000@Atlassian.JIRA>
References: <JIRA.12674620.1486057102000@Atlassian.JIRA>
	<JIRA.12674620.1486057102951@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674620.1486057102000.51219.1486057140347@Atlassian.JIRA>

Darran Lofthouse created WFLY-8016:
--------------------------------------

             Summary: Merge Elytron invocation integration topic branch.
                 Key: WFLY-8016
                 URL: https://issues.jboss.org/browse/WFLY-8016
             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 Feb  2 12:39:00 2017
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 2 Feb 2017 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8017) Upgrade FasterXML Jackson to
	2.8.6
In-Reply-To: <JIRA.12674621.1486057120000@Atlassian.JIRA>
References: <JIRA.12674621.1486057120000@Atlassian.JIRA>
	<JIRA.12674621.1486057120566@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674621.1486057120000.51226.1486057140532@Atlassian.JIRA>

Alessio Soldano created WFLY-8017:
-------------------------------------

             Summary: Upgrade FasterXML Jackson to 2.8.6
                 Key: WFLY-8017
                 URL: https://issues.jboss.org/browse/WFLY-8017
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Alessio Soldano
            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  Thu Feb  2 12:39:00 2017
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 2 Feb 2017 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8018) Upgrade FasterXML Jackson to
	2.8.6
In-Reply-To: <JIRA.12674622.1486057139000@Atlassian.JIRA>
References: <JIRA.12674622.1486057139000@Atlassian.JIRA>
	<JIRA.12674622.1486057139388@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674622.1486057139000.51235.1486057140782@Atlassian.JIRA>

Alessio Soldano created WFLY-8018:
-------------------------------------

             Summary: Upgrade FasterXML Jackson to 2.8.6
                 Key: WFLY-8018
                 URL: https://issues.jboss.org/browse/WFLY-8018
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Alessio Soldano
            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  Thu Feb  2 13:48:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 13:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8019) AUTH protocol should obtain
 X509 certificate from an Elytron capability
In-Reply-To: <JIRA.12674628.1486061279000@Atlassian.JIRA>
References: <JIRA.12674628.1486061279000@Atlassian.JIRA>
	<JIRA.12674628.1486061279260@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674628.1486061279000.51408.1486061280395@Atlassian.JIRA>

Paul Ferraro created WFLY-8019:
----------------------------------

             Summary: AUTH protocol should obtain X509 certificate from an Elytron capability
                 Key: WFLY-8019
                 URL: https://issues.jboss.org/browse/WFLY-8019
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering, Security
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 13:50:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 2 Feb 2017 13:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8020) SASL protocol should be
 configured from Elytron capabilities
In-Reply-To: <JIRA.12674629.1486061366000@Atlassian.JIRA>
References: <JIRA.12674629.1486061366000@Atlassian.JIRA>
	<JIRA.12674629.1486061366955@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674629.1486061366000.51416.1486061400147@Atlassian.JIRA>

Paul Ferraro created WFLY-8020:
----------------------------------

             Summary: SASL protocol should be configured from Elytron capabilities
                 Key: WFLY-8020
                 URL: https://issues.jboss.org/browse/WFLY-8020
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering, Security
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 17:47:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Feb 2017 17:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-910) Remove participant from SSO
 when remote logout failed
In-Reply-To: <JIRA.12674665.1486075619000@Atlassian.JIRA>
References: <JIRA.12674665.1486075619000@Atlassian.JIRA>
	<JIRA.12674665.1486075619366@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674665.1486075619000.52961.1486075620504@Atlassian.JIRA>

Pedro Igor created ELY-910:
------------------------------

             Summary: Remove participant from SSO when remote logout failed
                 Key: ELY-910
                 URL: https://issues.jboss.org/browse/ELY-910
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
    Affects Versions: 1.1.0.Beta21
            Reporter: Pedro Igor
            Assignee: Pedro Igor


We are not properly handle remote logout failures when something wrong happens when logging out a participant.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 18:16:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Feb 2017 18:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-911) Add method to obtain the
 request relative path
In-Reply-To: <JIRA.12674667.1486077339000@Atlassian.JIRA>
References: <JIRA.12674667.1486077339000@Atlassian.JIRA>
	<JIRA.12674667.1486077339256@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674667.1486077339000.53098.1486077360071@Atlassian.JIRA>

Pedro Igor created ELY-911:
------------------------------

             Summary: Add method to obtain the request relative path
                 Key: ELY-911
                 URL: https://issues.jboss.org/browse/ELY-911
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: HTTP
    Affects Versions: 1.1.0.Beta21
            Reporter: Pedro Igor
            Assignee: Pedro Igor






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 18:20:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 2 Feb 2017 18:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1935) Add
 :read-attribute-description operation
In-Reply-To: <JIRA.12659396.1478249847000@Atlassian.JIRA>
References: <JIRA.12659396.1478249847000@Atlassian.JIRA>
	<JIRA.12659396.1478249847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659396.1478249847000.53110.1486077600198@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358007#comment-13358007 ] 

Brian Stansberry commented on WFCORE-1935:
------------------------------------------

I have done quite a lot on this but I think I'll need to shelve it for a while, perhaps until the next release.

https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-1935

There are some edge cases here that need handling, and in a way that's comprehensible to the behavior of other ops. I'm talking about wildcard address handling scenarios. Those will take a bit of thought and it's doubtful I'll get to it before we hit WF Core 3.0.0.Beta1 in a week or so and need to stop feature work.

> Add :read-attribute-description operation
> -----------------------------------------
>
>                 Key: WFCORE-1935
>                 URL: https://issues.jboss.org/browse/WFCORE-1935
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Pavel Jelinek
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> In resource with many attributes which may or may not be ordered in _:read-resource-description_ operation result it's very hard to find description of a particular attribute. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 18:36:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Feb 2017 18:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout notification support for
 HTTP-based authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.53139.1486078560063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-904:
---------------------------
    Summary: Logout notification support for HTTP-based authentication mechanisms  (was: Logout support for HTTP-based authentication mechanisms)


> Logout notification support for HTTP-based authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 21:32:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Feb 2017 21:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout notification support for
 HTTP-based authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.53489.1486089120152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358043#comment-13358043 ] 

Pedro Igor edited comment on ELY-904 at 2/2/17 9:31 PM:
--------------------------------------------------------

[~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically.

I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. 


was (Author: pcraveiro):
[~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically.

I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request for during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. 

> Logout notification support for HTTP-based authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  2 21:32:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 2 Feb 2017 21:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout notification support for
 HTTP-based authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.53487.1486089120089@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358043#comment-13358043 ] 

Pedro Igor commented on ELY-904:
--------------------------------

[~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically.

I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request for during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. 

> Logout notification support for HTTP-based authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 02:58:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 02:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8021) JMS-Bridge ignore
 source-credential-reference attribute
In-Reply-To: <JIRA.12674703.1486108673000@Atlassian.JIRA>
References: <JIRA.12674703.1486108673000@Atlassian.JIRA>
	<JIRA.12674703.1486108673435@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674703.1486108673000.53662.1486108680984@Atlassian.JIRA>

Hynek ?v?bek created WFLY-8021:
----------------------------------

             Summary: 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: Darran Lofthouse


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  Fri Feb  3 02:58:01 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 02:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8021) JMS-Bridge ignore
 source-credential-reference attribute
In-Reply-To: <JIRA.12674703.1486108673000@Atlassian.JIRA>
References: <JIRA.12674703.1486108673000@Atlassian.JIRA>
	<JIRA.12674703.1486108673000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674703.1486108673000.53674.1486108681475@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned WFLY-8021:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> 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: Peter Skopek
>
> 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  Fri Feb  3 03:52:00 2017
From: issues at jboss.org (Daniele Pirola (JIRA))
Date: Fri, 3 Feb 2017 03:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7031) Redirect Port Fails to
 Redirect to 3rd Party HTTP Port
In-Reply-To: <JIRA.12648161.1472739224000@Atlassian.JIRA>
References: <JIRA.12648161.1472739224000@Atlassian.JIRA>
	<JIRA.12648161.1472739224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648161.1472739224000.53940.1486111920181@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358095#comment-13358095 ] 

Daniele Pirola commented on WFLY-7031:
--------------------------------------

Hi Bhaskara,
I have the same problem with wildfly 10.1.0.Final behind squid and apache httpd.
Finally I modify the {{ajp-listener}} specifying the attribute {{scheme}} like this:

{{ <ajp-listener name="ajp" socket-binding="ajp" *scheme="https"*/>}}

Now https call works fine and also redirect from http to https.
Probably this configuration could be more publicized inside wildfly documentation

> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
>                 Key: WFLY-7031
>                 URL: https://issues.jboss.org/browse/WFLY-7031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Joe Carder
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected.  I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 04:41:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-912) Create DirContext is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674726.1486114827000@Atlassian.JIRA>
References: <JIRA.12674726.1486114827000@Atlassian.JIRA>
	<JIRA.12674726.1486114827352@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674726.1486114827000.54349.1486114860227@Atlassian.JIRA>

Ondrej Lukas created ELY-912:
--------------------------------

             Summary: 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
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


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  Fri Feb  3 04:41:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-912) Create DirContext is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674726.1486114827000@Atlassian.JIRA>
References: <JIRA.12674726.1486114827000@Atlassian.JIRA>
	<JIRA.12674726.1486114827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674726.1486114827000.54352.1486114860355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-912:
-----------------------------
    Affects Version/s: 1.1.0.Beta21


> 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
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> 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  Fri Feb  3 04:41:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-912) Create DirContext is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674726.1486114827000@Atlassian.JIRA>
References: <JIRA.12674726.1486114827000@Atlassian.JIRA>
	<JIRA.12674726.1486114827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674726.1486114827000.54355.1486114860511@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-912:
-----------------------------
    Component/s: Realms


> 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: Darran Lofthouse
>
> 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  Fri Feb  3 04:43:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 3 Feb 2017 04:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-911) Add method to obtain the
 request relative path
In-Reply-To: <JIRA.12674667.1486077339000@Atlassian.JIRA>
References: <JIRA.12674667.1486077339000@Atlassian.JIRA>
	<JIRA.12674667.1486077339000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674667.1486077339000.54365.1486114980072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-911:
---------------------------
    Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/651, https://github.com/wildfly-security/elytron-web/pull/64  (was: https://github.com/wildfly-security/wildfly-elytron/pull/651)


> Add method to obtain the request relative path
> ----------------------------------------------
>
>                 Key: ELY-911
>                 URL: https://issues.jboss.org/browse/ELY-911
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 04:59:01 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Fri, 3 Feb 2017 04:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050725000@Atlassian.JIRA>
References: <JIRA.12674595.1486050725000@Atlassian.JIRA>
	<JIRA.12674595.1486050725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050725000.54455.1486115941831@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago Matias updated WFLY-8013:
-------------------------------
    Issue Type: Bug  (was: Enhancement)


> Out of memory exception after a number of remote deploys
> --------------------------------------------------------
>
>                 Key: WFLY-8013
>                 URL: https://issues.jboss.org/browse/WFLY-8013
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.1.0.Final
>         Environment: Server: Ubuntu 16.04.1 LTS x64
> bq. 
> bq. Startup arguments:
> bq. 
> bq. 
> bq.  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0
>            Reporter: Tiago Matias
>            Assignee: Jason Greene
>            Priority: Minor
>
> Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.
> *Full error log of maven.*
> {quote}
> [INFO] Authenticating against security realm: ManagementRealm
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 47.630 s
> [INFO] Finished at: 2017-02-02T15:38:04+00:00
> [INFO] Final Memory: 22M/290M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
> . Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
> backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
> [ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
> vailable dependencies" => undefined}}}
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 04:59:02 2017
From: issues at jboss.org (Tiago Matias (JIRA))
Date: Fri, 3 Feb 2017 04:59:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8013) Out of memory exception after
 a number of remote deploys
In-Reply-To: <JIRA.12674595.1486050725000@Atlassian.JIRA>
References: <JIRA.12674595.1486050725000@Atlassian.JIRA>
	<JIRA.12674595.1486050725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674595.1486050725000.54459.1486115942034@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tiago Matias updated WFLY-8013:
-------------------------------
    Priority: Major  (was: Minor)


> Out of memory exception after a number of remote deploys
> --------------------------------------------------------
>
>                 Key: WFLY-8013
>                 URL: https://issues.jboss.org/browse/WFLY-8013
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.1.0.Final
>         Environment: Server: Ubuntu 16.04.1 LTS x64
> bq. 
> bq. Startup arguments:
> bq. 
> bq. 
> bq.  java -D[Standalone] -server -Xms256m -Xmx8096m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/opt/wildfly/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/standalone/configuration/logging.properties -jar /opt/wildfly/jboss-modules.jar -mp /opt/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly -Djboss.server.base.dir=/opt/wildfly/standalone -c standalone.xml -b 0.0.0.0
>            Reporter: Tiago Matias
>            Assignee: Jason Greene
>
> Using the wildfly-maven-plugin for remotely deploying a WAR file do Wildfly and, after a few deploys (between 5 and 10) An outofmemory error emerges, requiring a full server restart.
> *Full error log of maven.*
> {quote}
> [INFO] Authenticating against security realm: ManagementRealm
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 47.630 s
> [INFO] Finished at: 2017-02-02T15:38:04+00:00
> [INFO] Final Memory: 22M/290M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.1.0.Final:deploy (default) on project MyProject: Failed to execute goal deploy: {"WFLYCTL0062: Composite operation failed and was rolled back
> . Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"backoffice.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"
> backoffice.war\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"backoffice.war\"
> [ERROR] Caused by: java.lang.OutOfMemoryError: Metaspace"},"WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"MyProject.war\".POST_MODULE"],"WFLYCTL0180: Services with missing/una
> vailable dependencies" => undefined}}}
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:14:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 06:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-913) Incorrect username is passed to
 principal when principal-transformers are enabled
In-Reply-To: <JIRA.12674747.1486120406000@Atlassian.JIRA>
References: <JIRA.12674747.1486120406000@Atlassian.JIRA>
	<JIRA.12674747.1486120406649@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674747.1486120406000.54979.1486120440329@Atlassian.JIRA>

Ondrej Lukas created ELY-913:
--------------------------------

             Summary: Incorrect username is passed to principal when principal-transformers are enabled
                 Key: ELY-913
                 URL: https://issues.jboss.org/browse/ELY-913
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case when some principal-transformers are used for transforming principal in security domain then final username which is used for authentication and later for authorization is: input_username transformed by pre-realm-principal-transformer, post-realm-principal-transformer and realm principal-transformer. However Principal assigned to SecurityIdentity uses only name input_username transformed by pre-realm-principal-transformer.

It seems it is caused by passing {{preRealmPrincipal}} as fourth parameter in https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L1011

Value of SecurityIdentity.getPrincipal() can be seen when trace log is enabled due to https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/SecurityDomain.java#L451

Since it seems there is currently no documentation related to this topic I cannot say whether it is real bug. [~dlofthouse] could you please provide some clarification?

Log (see Steps to Reproduce for more details about configuration):
{code}
TRACE [org.wildfly.security] (default task-3) Principal assigning: [user], pre-realm rewritten: [user1], realm name: [ApplicationRealm], post realm rewritten: [user12], realm rewritten: [user123]
TRACE [org.wildfly.security] (default task-3) Attempting to authenticate account user123 using LegacyPropertiesSecurityRealm.
...
TRACE [org.wildfly.security] (default task-3) Role mapping: principal [user1] -> decoded roles [JBossAdmin] -> realm mapped roles [JBossAdmin] -> domain mapped roles [JBossAdmin]
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:14:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 06:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-913) Incorrect username is passed to
 principal when principal-transformers are enabled
In-Reply-To: <JIRA.12674747.1486120407000@Atlassian.JIRA>
References: <JIRA.12674747.1486120407000@Atlassian.JIRA>
	<JIRA.12674747.1486120407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674747.1486120407000.54982.1486120440389@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-913:
-----------------------------
    Affects Version/s: 1.1.0.Beta21


> Incorrect username is passed to principal when principal-transformers are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: ELY-913
>                 URL: https://issues.jboss.org/browse/ELY-913
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when some principal-transformers are used for transforming principal in security domain then final username which is used for authentication and later for authorization is: input_username transformed by pre-realm-principal-transformer, post-realm-principal-transformer and realm principal-transformer. However Principal assigned to SecurityIdentity uses only name input_username transformed by pre-realm-principal-transformer.
> It seems it is caused by passing {{preRealmPrincipal}} as fourth parameter in https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L1011
> Value of SecurityIdentity.getPrincipal() can be seen when trace log is enabled due to https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/SecurityDomain.java#L451
> Since it seems there is currently no documentation related to this topic I cannot say whether it is real bug. [~dlofthouse] could you please provide some clarification?
> Log (see Steps to Reproduce for more details about configuration):
> {code}
> TRACE [org.wildfly.security] (default task-3) Principal assigning: [user], pre-realm rewritten: [user1], realm name: [ApplicationRealm], post realm rewritten: [user12], realm rewritten: [user123]
> TRACE [org.wildfly.security] (default task-3) Attempting to authenticate account user123 using LegacyPropertiesSecurityRealm.
> ...
> TRACE [org.wildfly.security] (default task-3) Role mapping: principal [user1] -> decoded roles [JBossAdmin] -> realm mapped roles [JBossAdmin] -> domain mapped roles [JBossAdmin]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:30:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 06:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-914) Elytron LdapSearch is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674750.1486121342000@Atlassian.JIRA>
References: <JIRA.12674750.1486121342000@Atlassian.JIRA>
	<JIRA.12674750.1486121342129@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674750.1486121342000.55059.1486121400292@Atlassian.JIRA>

Ondrej Lukas created ELY-914:
--------------------------------

             Summary: Elytron LdapSearch is not able to log arrays correctly
                 Key: ELY-914
                 URL: https://issues.jboss.org/browse/ELY-914
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when log debug level for class {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.LdapSearch}} is enabled, then arguments and returning attributes are not able to be logged correctly because they are arrays.

See:
{code}
Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@45535736]. Returning attributes are [[Ljava.lang.String;@331d3f34]
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:30:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 06:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-914) Elytron LdapSearch is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674750.1486121342000@Atlassian.JIRA>
References: <JIRA.12674750.1486121342000@Atlassian.JIRA>
	<JIRA.12674750.1486121342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674750.1486121342000.55069.1486121400652@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-914:
-----------------------------
    Component/s: Realms


> Elytron LdapSearch is not able to log arrays correctly
> ------------------------------------------------------
>
>                 Key: ELY-914
>                 URL: https://issues.jboss.org/browse/ELY-914
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when log debug level for class {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.LdapSearch}} is enabled, then arguments and returning attributes are not able to be logged correctly because they are arrays.
> See:
> {code}
> Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@45535736]. Returning attributes are [[Ljava.lang.String;@331d3f34]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:30:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 06:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-914) Elytron LdapSearch is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674750.1486121342000@Atlassian.JIRA>
References: <JIRA.12674750.1486121342000@Atlassian.JIRA>
	<JIRA.12674750.1486121342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674750.1486121342000.55066.1486121400558@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-914:
-----------------------------
    Affects Version/s: 1.1.0.Beta21


> Elytron LdapSearch is not able to log arrays correctly
> ------------------------------------------------------
>
>                 Key: ELY-914
>                 URL: https://issues.jboss.org/browse/ELY-914
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when log debug level for class {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.LdapSearch}} is enabled, then arguments and returning attributes are not able to be logged correctly because they are arrays.
> See:
> {code}
> Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@45535736]. Returning attributes are [[Ljava.lang.String;@331d3f34]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:44:01 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 3 Feb 2017 06:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7885) Persistent calendar timer
 force logging for each invocation if the deployed-class has changed
In-Reply-To: <JIRA.12671015.1484310939000@Atlassian.JIRA>
References: <JIRA.12671015.1484310939000@Atlassian.JIRA>
	<JIRA.12671015.1484310939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671015.1484310939000.55177.1486122241660@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-7885:
--------------------------------

    Assignee: Ingo Weiss


> 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
>
> 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  Fri Feb  3 06:54:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 3 Feb 2017 06:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.55267.1486122840432@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358234#comment-13358234 ] 

Paul Ferraro commented on WFLY-8014:
------------------------------------

[~michpetrov] Good question. They should behave the same.  It seems that without that flag the store=file:add puts the server in reload-required state, while the store=remote:add fails with a duplicate service exception.  I'll reopen this for investigation and note the workaround in the description.

> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:55:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 3 Feb 2017 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.55275.1486122900257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reopened WFLY-8014:
--------------------------------


> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 06:56:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 3 Feb 2017 06:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8014) Remote store cannot be added
 to a cache via CLI
In-Reply-To: <JIRA.12674603.1486052244000@Atlassian.JIRA>
References: <JIRA.12674603.1486052244000@Atlassian.JIRA>
	<JIRA.12674603.1486052244000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674603.1486052244000.55287.1486122960805@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8014:
-------------------------------
    Workaround Description: Both store=file:add and store=remove:add succeed when the {allow-resource-service-restart=true} invocation flag is used.


> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
>                 Key: WFLY-8014
>                 URL: https://issues.jboss.org/browse/WFLY-8014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Michal Petrov
>            Assignee: Paul Ferraro
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
>     "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 07:13:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 07:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8022) Autocomplete doesn't work
 properly in credential-reference.store attribute.
In-Reply-To: <JIRA.12674772.1486123960000@Atlassian.JIRA>
References: <JIRA.12674772.1486123960000@Atlassian.JIRA>
	<JIRA.12674772.1486123960402@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674772.1486123960000.55619.1486123980885@Atlassian.JIRA>

Hynek ?v?bek created WFLY-8022:
----------------------------------

             Summary: Autocomplete doesn't work properly in credential-reference.store attribute.
                 Key: WFLY-8022
                 URL: https://issues.jboss.org/browse/WFLY-8022
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse


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=<TAB>
{code}





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb  3 07:14:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 07:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8022) Autocomplete doesn't work
 properly in credential-reference.store attribute.
In-Reply-To: <JIRA.12674772.1486123960000@Atlassian.JIRA>
References: <JIRA.12674772.1486123960000@Atlassian.JIRA>
	<JIRA.12674772.1486123960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674772.1486123960000.55633.1486124040441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned WFLY-8022:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> Autocomplete doesn't work properly in credential-reference.store attribute.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-8022
>                 URL: https://issues.jboss.org/browse/WFLY-8022
>             Project: WildFly
>          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=<TAB>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb  3 07:16:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 07:16:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8022) Autocomplete doesn't work
 properly in credential-reference.store attribute.
In-Reply-To: <JIRA.12674772.1486123960000@Atlassian.JIRA>
References: <JIRA.12674772.1486123960000@Atlassian.JIRA>
	<JIRA.12674772.1486123960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674772.1486123960000.55672.1486124161416@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358259#comment-13358259 ] 

Darran Lofthouse commented on WFLY-8022:
----------------------------------------

This is likely a duplicate of WFCORE-2245

> Autocomplete doesn't work properly in credential-reference.store attribute.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-8022
>                 URL: https://issues.jboss.org/browse/WFLY-8022
>             Project: WildFly
>          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=<TAB>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb  3 07:17:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 3 Feb 2017 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout notification support for
 HTTP-based authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.55676.1486124220289@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358260#comment-13358260 ] 

Pedro Igor commented on ELY-904:
--------------------------------

I stepped back and pushed changes related with the addition of a logout method to {{HttpServerAuthenticationMechanism}}.

Support this via notification is really possible for session based mechanism, given that usually we just need to invalidate session and not write to the response.

If our HTTP API were allowing mechs to write to the response without necessary calling one of those "complete methods" (authenticationComplete, noAuthInProgress, etc) we can avoid adding this method and just support LOGOUT notification in our API.  

> Logout notification support for HTTP-based authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 07:17:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8023) Autocomplete doesn't work
 properly in credential-reference.alias attribute.
In-Reply-To: <JIRA.12674774.1486124190000@Atlassian.JIRA>
References: <JIRA.12674774.1486124190000@Atlassian.JIRA>
	<JIRA.12674774.1486124190492@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674774.1486124190000.55679.1486124220393@Atlassian.JIRA>

Hynek ?v?bek created WFLY-8023:
----------------------------------

             Summary: Autocomplete doesn't work properly in credential-reference.alias attribute.
                 Key: WFLY-8023
                 URL: https://issues.jboss.org/browse/WFLY-8023
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Hynek ?v?bek
            Assignee: Darran Lofthouse


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=<TAB>
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb  3 07:17:00 2017
From: issues at jboss.org (=?UTF-8?Q?Hynek_=C5=A0v=C3=A1bek_=28JIRA=29?=)
Date: Fri, 3 Feb 2017 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8023) Autocomplete doesn't work
 properly in credential-reference.alias attribute.
In-Reply-To: <JIRA.12674774.1486124190000@Atlassian.JIRA>
References: <JIRA.12674774.1486124190000@Atlassian.JIRA>
	<JIRA.12674774.1486124190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674774.1486124190000.55691.1486124220815@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hynek ?v?bek reassigned WFLY-8023:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> Autocomplete doesn't work properly in credential-reference.alias attribute.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-8023
>                 URL: https://issues.jboss.org/browse/WFLY-8023
>             Project: WildFly
>          Issue Type: Bug
>          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=<TAB>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb  3 07:22:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 3 Feb 2017 07:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-913) Incorrect username is passed to
 principal when principal-transformers are enabled
In-Reply-To: <JIRA.12674747.1486120407000@Atlassian.JIRA>
References: <JIRA.12674747.1486120407000@Atlassian.JIRA>
	<JIRA.12674747.1486120407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674747.1486120407000.55721.1486124520213@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358265#comment-13358265 ] 

David Lloyd commented on ELY-913:
---------------------------------

This is intentional. The domain principal is meant to be unique per domain, whereas the realm principal need only be unique per realm. So if I have two realms, for example one for customers and one for employees, and they both contain an identity with the same name, I can use post-realm rewriters to disambiguate them.

Example 1: "David/cust" -> map to customer realm -> "David"
Example 2: "David/emp" -> map to employee realm -> "David"

> Incorrect username is passed to principal when principal-transformers are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: ELY-913
>                 URL: https://issues.jboss.org/browse/ELY-913
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when some principal-transformers are used for transforming principal in security domain then final username which is used for authentication and later for authorization is: input_username transformed by pre-realm-principal-transformer, post-realm-principal-transformer and realm principal-transformer. However Principal assigned to SecurityIdentity uses only name input_username transformed by pre-realm-principal-transformer.
> It seems it is caused by passing {{preRealmPrincipal}} as fourth parameter in https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L1011
> Value of SecurityIdentity.getPrincipal() can be seen when trace log is enabled due to https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/SecurityDomain.java#L451
> Since it seems there is currently no documentation related to this topic I cannot say whether it is real bug. [~dlofthouse] could you please provide some clarification?
> Log (see Steps to Reproduce for more details about configuration):
> {code}
> TRACE [org.wildfly.security] (default task-3) Principal assigning: [user], pre-realm rewritten: [user1], realm name: [ApplicationRealm], post realm rewritten: [user12], realm rewritten: [user123]
> TRACE [org.wildfly.security] (default task-3) Attempting to authenticate account user123 using LegacyPropertiesSecurityRealm.
> ...
> TRACE [org.wildfly.security] (default task-3) Role mapping: principal [user1] -> decoded roles [JBossAdmin] -> realm mapped roles [JBossAdmin] -> domain mapped roles [JBossAdmin]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 07:37:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 3 Feb 2017 07:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-913) Incorrect username is passed to
 principal when principal-transformers are enabled
In-Reply-To: <JIRA.12674747.1486120407000@Atlassian.JIRA>
References: <JIRA.12674747.1486120407000@Atlassian.JIRA>
	<JIRA.12674747.1486120407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674747.1486120407000.55887.1486125420302@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas closed ELY-913.
----------------------------
    Resolution: Rejected


Ok, I understand it now. Thanks for the clarification. I am closing this issue since this is not a bug.

> Incorrect username is passed to principal when principal-transformers are enabled
> ---------------------------------------------------------------------------------
>
>                 Key: ELY-913
>                 URL: https://issues.jboss.org/browse/ELY-913
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when some principal-transformers are used for transforming principal in security domain then final username which is used for authentication and later for authorization is: input_username transformed by pre-realm-principal-transformer, post-realm-principal-transformer and realm principal-transformer. However Principal assigned to SecurityIdentity uses only name input_username transformed by pre-realm-principal-transformer.
> It seems it is caused by passing {{preRealmPrincipal}} as fourth parameter in https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/ServerAuthenticationContext.java#L1011
> Value of SecurityIdentity.getPrincipal() can be seen when trace log is enabled due to https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec60ec441986b5f830bb111283/src/main/java/org/wildfly/security/auth/server/SecurityDomain.java#L451
> Since it seems there is currently no documentation related to this topic I cannot say whether it is real bug. [~dlofthouse] could you please provide some clarification?
> Log (see Steps to Reproduce for more details about configuration):
> {code}
> TRACE [org.wildfly.security] (default task-3) Principal assigning: [user], pre-realm rewritten: [user1], realm name: [ApplicationRealm], post realm rewritten: [user12], realm rewritten: [user123]
> TRACE [org.wildfly.security] (default task-3) Attempting to authenticate account user123 using LegacyPropertiesSecurityRealm.
> ...
> TRACE [org.wildfly.security] (default task-3) Role mapping: principal [user1] -> decoded roles [JBossAdmin] -> realm mapped roles [JBossAdmin] -> domain mapped roles [JBossAdmin]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 07:54:01 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Fri, 3 Feb 2017 07:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-915) Elytron filesystem caching
 realm should cache attributes and credentials
In-Reply-To: <JIRA.12674786.1486126284000@Atlassian.JIRA>
References: <JIRA.12674786.1486126284000@Atlassian.JIRA>
	<JIRA.12674786.1486126284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674786.1486126284000.55996.1486126441140@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek moved JBEAP-8663 to ELY-915:
-----------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-915  (was: JBEAP-8663)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Realms
                           (was: Security)
    Affects Version/s: 1.1.0.Beta21
                           (was: 7.1.0.DR11)


> Elytron filesystem caching realm should cache attributes and credentials
> ------------------------------------------------------------------------
>
>                 Key: ELY-915
>                 URL: https://issues.jboss.org/browse/ELY-915
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Kotek
>
> Elytron caching realm backed by filesystem realm provides caching for identity objects but not for related credentials and attributes.
> Credentials and attributes should not be loaded from file system for a cache hit.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 08:06:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Fri, 3 Feb 2017 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-916) Add ability to use specified
 Provider[] when creating KeyStore instance in KeyStoreCredentialStore
In-Reply-To: <JIRA.12674788.1486127142000@Atlassian.JIRA>
References: <JIRA.12674788.1486127142000@Atlassian.JIRA>
	<JIRA.12674788.1486127142286@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674788.1486127142000.56101.1486127160233@Atlassian.JIRA>

Peter Skopek created ELY-916:
--------------------------------

             Summary: Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore
                 Key: ELY-916
                 URL: https://issues.jboss.org/browse/ELY-916
             Project: WildFly Elytron
          Issue Type: Task
          Components: Credential Store
            Reporter: Peter Skopek
            Assignee: Peter Skopek


Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore.

This will give us opportunity to consume custom KeyStore (for example for FIPS certified CredentialStore).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 08:12:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Fri, 3 Feb 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-916) Add ability to use specified
 Provider[] when creating KeyStore instance in KeyStoreCredentialStore
In-Reply-To: <JIRA.12674788.1486127142000@Atlassian.JIRA>
References: <JIRA.12674788.1486127142000@Atlassian.JIRA>
	<JIRA.12674788.1486127142000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674788.1486127142000.56127.1486127520081@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated ELY-916:
-----------------------------
    Description: 
Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore.

This will give us opportunity to use custom KeyStore (for example for FIPS certified CredentialStore).

  was:
Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore.

This will give us opportunity to consume custom KeyStore (for example for FIPS certified CredentialStore).



> Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore
> --------------------------------------------------------------------------------------------------
>
>                 Key: ELY-916
>                 URL: https://issues.jboss.org/browse/ELY-916
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Credential Store
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore.
> This will give us opportunity to use custom KeyStore (for example for FIPS certified CredentialStore).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 08:40:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 3 Feb 2017 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8024) Upgrade Weld to 2.4.2.Final
In-Reply-To: <JIRA.12674791.1486129179000@Atlassian.JIRA>
References: <JIRA.12674791.1486129179000@Atlassian.JIRA>
	<JIRA.12674791.1486129179653@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674791.1486129179000.56303.1486129200445@Atlassian.JIRA>

Martin Kouba created WFLY-8024:
----------------------------------

             Summary: Upgrade Weld to 2.4.2.Final
                 Key: WFLY-8024
                 URL: https://issues.jboss.org/browse/WFLY-8024
             Project: WildFly
          Issue Type: Component Upgrade
          Components: CDI / Weld
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 11.0.0.Alpha1


See also http://weld.cdi-spec.org/news/2017/02/02/weld-242Final/.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 08:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-917) Release WildFly Elytron
	1.1.0.Beta22
In-Reply-To: <JIRA.12674799.1486130208000@Atlassian.JIRA>
References: <JIRA.12674799.1486130208000@Atlassian.JIRA>
	<JIRA.12674799.1486130208272@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674799.1486130208000.56483.1486130220231@Atlassian.JIRA>

Darran Lofthouse created ELY-917:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta22
                 Key: ELY-917
                 URL: https://issues.jboss.org/browse/ELY-917
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta22






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.56611.1486131363313@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-917) Release WildFly Elytron
	1.1.0.Beta22
In-Reply-To: <JIRA.12674799.1486130208000@Atlassian.JIRA>
References: <JIRA.12674799.1486130208000@Atlassian.JIRA>
	<JIRA.12674799.1486130208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674799.1486130208000.56602.1486131363056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-917.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta22
> ------------------------------------
>
>                 Key: ELY-917
>                 URL: https://issues.jboss.org/browse/ELY-917
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta22
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.56614.1486131363366@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.56617.1486131363450@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.56621.1486131363609@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.56624.1486131363660@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.56627.1486131363726@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.56656.1486131364448@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.Beta23
>
>
> 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  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.56630.1486131363789@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.56645.1486131364184@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-835) SecurityIdentity Automatic
	Outflow
In-Reply-To: <JIRA.12667816.1481802782000@Atlassian.JIRA>
References: <JIRA.12667816.1481802782000@Atlassian.JIRA>
	<JIRA.12667816.1481802782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667816.1481802782000.56641.1486131364064@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-835:
---------------------------------
    Fix Version/s: 1.1.0.Beta23
                       (was: 1.1.0.Beta22)


> SecurityIdentity Automatic Outflow
> ----------------------------------
>
>                 Key: ELY-835
>                 URL: https://issues.jboss.org/browse/ELY-835
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta23
>
>
> We previously discussed that when runAs is called on a SecurityIdentity this should pro-actively outflow to predefined security domains (which it has in trusted-security-domains?) so it does not need to be manually inflowed at a later point.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.56635.1486131363919@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-765) ServiceLoader Provider and
 SaslClientFactory discovery should be able to use system ClassLoader
In-Reply-To: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.56665.1486131364782@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.56659.1486131364559@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.56662.1486131364691@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.56669.1486131364950@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.56652.1486131364327@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.Beta23
>
>
> 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  Fri Feb  3 09:16:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.56648.1486131364245@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.56672.1486131365101@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.56676.1486131365259@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler
 interactions to a common base class for HTTP mechanisms, .
In-Reply-To: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.56679.1486131365405@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.56682.1486131365526@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.56689.1486131365883@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.56686.1486131365770@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.56692.1486131365985@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.56696.1486131366115@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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
>             Fix For: 1.1.0.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.56699.1486131366262@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be
 considered to be static nested in Elytron
In-Reply-To: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.56703.1486131366353@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.56708.1486131366456@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.56714.1486131366621@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.56711.1486131366548@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.56724.1486131366940@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.56720.1486131366851@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.56717.1486131366757@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.56727.1486131366995@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16: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: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.56730.1486131367056@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16: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: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.56733.1486131367123@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.56736.1486131367304@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.56739.1486131367445@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.56744.1486131367544@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.56747.1486131367603@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.56751.1486131367685@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.56754.1486131367746@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>
> 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  Fri Feb  3 09:16:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:16:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.56757.1486131367858@Atlassian.JIRA>


     [ 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.Beta23
                       (was: 1.1.0.Beta22)


> 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.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 3 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2263) Upgrade WildFly Elytron to
	1.1.0.Beta22
In-Reply-To: <JIRA.12674803.1486131458000@Atlassian.JIRA>
References: <JIRA.12674803.1486131458000@Atlassian.JIRA>
	<JIRA.12674803.1486131458305@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674803.1486131458000.56765.1486131480500@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2263:
----------------------------------------

             Summary: Upgrade WildFly Elytron to 1.1.0.Beta22
                 Key: WFCORE-2263
                 URL: https://issues.jboss.org/browse/WFCORE-2263
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:32:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 3 Feb 2017 09:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-918) Allow HTTP mechanisms to decide
 if response should be sent when authentication is in progress
In-Reply-To: <JIRA.12674807.1486132276000@Atlassian.JIRA>
References: <JIRA.12674807.1486132276000@Atlassian.JIRA>
	<JIRA.12674807.1486132276166@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674807.1486132276000.56851.1486132320225@Atlassian.JIRA>

Pedro Igor created ELY-918:
------------------------------

             Summary: Allow HTTP mechanisms to decide if response should be sent when authentication is in progress
                 Key: ELY-918
                 URL: https://issues.jboss.org/browse/ELY-918
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: HTTP
    Affects Versions: 1.1.0.Beta21
            Reporter: Pedro Igor
            Assignee: Pedro Igor


Currently, mechanisms are not allowed to decide if a challenge should be sent or not when processing a request to path where authentication is not required.

Currently, we always write to the response regardless if authentication if required or not, making impossible to mechanisms decide what you do in cases where a request is a for a non-protected resource and an authentication challenge should not be sent.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 09:34:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 3 Feb 2017 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-919) Coverity: default platform
 encoding used in DefaultSingleSignOnSessionFactory
In-Reply-To: <JIRA.12672831.1485265229000@Atlassian.JIRA>
References: <JIRA.12672831.1485265229000@Atlassian.JIRA>
	<JIRA.12672831.1485265229000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672831.1485265229000.56898.1486132440377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7953 to ELY-919:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-919  (was: WFLY-7953)
          Component/s: HTTP
                           (was: Security)
    Affects Version/s: 1.1.0.Beta21
                           (was: 11.0.0.Alpha1)


> Coverity: default platform encoding used in DefaultSingleSignOnSessionFactory
> -----------------------------------------------------------------------------
>
>                 Key: ELY-919
>                 URL: https://issues.jboss.org/browse/ELY-919
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity static-analysis scan found a String to byte conversion (4xoccurences of {{getBytes()}}) with default platform encoding in the DefaultSingleSignOnSessionFactory method.
> Following code
> {code:java|title=DefaultSingleSignOnSessionFactory.java}
>     @Override
>     public String createLogoutParameter(String sessionId) {
>         try {
>             Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
>             signature.initSign(this.privateKey);
>             Base64.Encoder urlEncoder = Base64.getUrlEncoder();
>             return sessionId + "." + ByteIterator.ofBytes(urlEncoder.encode(ByteIterator.ofBytes(sessionId.getBytes()).sign(signature).drain())).asUtf8String().drainToString();
>         } catch (NoSuchAlgorithmException | InvalidKeyException e) {
>             throw new IllegalStateException(e);
>         }
>     }
>     
>     @Override
>     public String verifyLogoutParameter(String parameter) {
>         String[] parts = parameter.split("\\.");
>         if (parts.length != 2) {
>             throw new IllegalArgumentException(parameter);
>         }
>         try {
>             String localSessionId = ByteIterator.ofBytes(parts[0].getBytes()).asUtf8String().drainToString();
>             Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
>             signature.initVerify(this.certificate);
>             signature.update(localSessionId.getBytes());
>             Base64.Decoder urlDecoder = Base64.getUrlDecoder();
>             if (!ByteIterator.ofBytes(urlDecoder.decode(parts[1].getBytes())).verify(signature)) {
>                 throw log.httpMechSsoInvalidLogoutMessage(localSessionId);
>             }
>             return localSessionId;
>         } catch (NoSuchAlgorithmException | InvalidKeyException e) {
>             throw new IllegalStateException(e);
>         } catch (SignatureException e) {
>             throw new IllegalArgumentException(parameter, e);
>         }
>     }
> {code}                                                                                                                                                                                                             
> The encoding should be specified as argument.
> Setting with high priority, because once default platform encoding UTF-16 will be set, funcionality  do not need to work as intended. Especially when combined with {{asUtf8String()}}, which implies specifying default encoding UTF-8.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8675870&defectInstanceId=2164160&mergedDefectId=1396938
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8675870&defectInstanceId=2164161&mergedDefectId=1396939



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 10:12:01 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 3 Feb 2017 10:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-904) Logout notification support for
 HTTP-based authentication mechanisms
In-Reply-To: <JIRA.12674184.1485958124000@Atlassian.JIRA>
References: <JIRA.12674184.1485958124000@Atlassian.JIRA>
	<JIRA.12674184.1485958124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674184.1485958124000.57310.1486134721850@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor updated ELY-904:
---------------------------
    Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/652, https://github.com/wildfly-security/elytron-web/pull/66  (was: https://github.com/wildfly-security/elytron-web/pull/66)


> Logout notification support for HTTP-based authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-904
>                 URL: https://issues.jboss.org/browse/ELY-904
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method  {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 10:23:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 3 Feb 2017 10:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8024) Upgrade Weld to 2.4.2.Final
In-Reply-To: <JIRA.12674791.1486129180000@Atlassian.JIRA>
References: <JIRA.12674791.1486129180000@Atlassian.JIRA>
	<JIRA.12674791.1486129180000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674791.1486129180000.57465.1486135380772@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358428#comment-13358428 ] 

Martin Kouba commented on WFLY-8024:
------------------------------------

We found a problem which only occurs if a {{SecurityManager}} is present. See also WELD-2328. We're going to release 2.4.2.SP1 and then send a new PR.

> Upgrade Weld to 2.4.2.Final
> ---------------------------
>
>                 Key: WFLY-8024
>                 URL: https://issues.jboss.org/browse/WFLY-8024
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 11.0.0.Alpha1
>
>
> See also http://weld.cdi-spec.org/news/2017/02/02/weld-242Final/.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 10:23:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 3 Feb 2017 10:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8024) Upgrade Weld to 2.4.2.SP1
In-Reply-To: <JIRA.12674791.1486129180000@Atlassian.JIRA>
References: <JIRA.12674791.1486129180000@Atlassian.JIRA>
	<JIRA.12674791.1486129180000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674791.1486129180000.57471.1486135380904@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-8024:
-------------------------------
    Summary: Upgrade Weld to 2.4.2.SP1  (was: Upgrade Weld to 2.4.2.Final)


> Upgrade Weld to 2.4.2.SP1
> -------------------------
>
>                 Key: WFLY-8024
>                 URL: https://issues.jboss.org/browse/WFLY-8024
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: CDI / Weld
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 11.0.0.Alpha1
>
>
> See also http://weld.cdi-spec.org/news/2017/02/02/weld-242Final/.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 10:29:00 2017
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Fri, 3 Feb 2017 10:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8025) Alternatives attribute
 "domain" doesn't exist in modcluster subsystem
In-Reply-To: <JIRA.12674830.1486135726000@Atlassian.JIRA>
References: <JIRA.12674830.1486135726000@Atlassian.JIRA>
	<JIRA.12674830.1486135726084@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674830.1486135726000.57557.1486135740235@Atlassian.JIRA>

Claudio Miranda created WFLY-8025:
-------------------------------------

             Summary: Alternatives attribute "domain" doesn't exist in modcluster subsystem
                 Key: WFLY-8025
                 URL: https://issues.jboss.org/browse/WFLY-8025
             Project: WildFly
          Issue Type: Bug
          Components: mod_cluster
            Reporter: Claudio Miranda
            Assignee: Radoslav Husar


modcluster resource contains the following attribute definition for "load-balancing-group"
{code}
"load-balancing-group" => {
    "type" => STRING,
    "description" => "loadBalancingGroup name.",
    "expressions-allowed" => true,
    "required" => false,
    "nillable" => true,
    "alternatives" => ["domain"],
    "min-length" => 1L,
    "max-length" => 2147483647L,
    "access-type" => "read-write",
    "storage" => "configuration",
    "restart-required" => "all-services"
},
{code}

But the alternatives constraint specifies a "domain" attribute that doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 10:50:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 3 Feb 2017 10:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-15) [QE] - JMAN4-163 - Track
 EAP servers connecting to the middleware manager
In-Reply-To: <JIRA.12673927.1485870392000@Atlassian.JIRA>
References: <JIRA.12673927.1485870392000@Atlassian.JIRA>
	<JIRA.12673927.1485870392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673927.1485870392000.57690.1486137000271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Mahoney updated HAWKULARQE-15:
-----------------------------------
    Priority: Major  (was: Minor)


> [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  Fri Feb  3 11:01:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 3 Feb 2017 11:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-28) hawkular-qe-manual
In-Reply-To: <JIRA.12674839.1486137657000@Atlassian.JIRA>
References: <JIRA.12674839.1486137657000@Atlassian.JIRA>
	<JIRA.12674839.1486137657488@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674839.1486137657000.57752.1486137660195@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-28:
--------------------------------------

             Summary: hawkular-qe-manual
                 Key: HAWKULARQE-28
                 URL: https://issues.jboss.org/browse/HAWKULARQE-28
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Matt Mahoney
            Assignee: mfoley user






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:02:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 3 Feb 2017 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-29) hawkular-qe-automation
In-Reply-To: <JIRA.12674840.1486137701000@Atlassian.JIRA>
References: <JIRA.12674840.1486137701000@Atlassian.JIRA>
	<JIRA.12674840.1486137701469@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674840.1486137701000.57762.1486137720482@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-29:
--------------------------------------

             Summary: hawkular-qe-automation
                 Key: HAWKULARQE-29
                 URL: https://issues.jboss.org/browse/HAWKULARQE-29
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Matt Mahoney
            Assignee: mfoley user






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:42:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4407) Upgrade wildfly-core to
	1.0.0.Beta1
In-Reply-To: <JIRA.12564891.1425551891000@Atlassian.JIRA>
References: <JIRA.12564891.1425551891000@Atlassian.JIRA>
	<JIRA.12564891.1425551891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564891.1425551891000.58261.1486140120639@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358494#comment-13358494 ] 

RH Bugzilla Integration commented on WFLY-4407:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from VERIFIED to CLOSED

> Upgrade wildfly-core to 1.0.0.Beta1
> -----------------------------------
>
>                 Key: WFLY-4407
>                 URL: https://issues.jboss.org/browse/WFLY-4407
>             Project: WildFly
>          Issue Type: Component Upgrade
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Jason Greene
>             Fix For: 9.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:42:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4404) View does not inherit
 'default' methods from interfaces( JDK8 )
In-Reply-To: <JIRA.12564873.1425545957000@Atlassian.JIRA>
References: <JIRA.12564873.1425545957000@Atlassian.JIRA>
	<JIRA.12564873.1425545957000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564873.1425545957000.58265.1486140120797@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358495#comment-13358495 ] 

RH Bugzilla Integration commented on WFLY-4404:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from VERIFIED to CLOSED

> View does not inherit 'default' methods from interfaces( JDK8 )
> ---------------------------------------------------------------
>
>                 Key: WFLY-4404
>                 URL: https://issues.jboss.org/browse/WFLY-4404
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 10.0.0.CR5
>
>
> View and View service do not inherit JDK8 'default' methods from interfaces.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:42:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-725) Remove ClassIndex from the
	server module
In-Reply-To: <JIRA.12573418.1433162743000@Atlassian.JIRA>
References: <JIRA.12573418.1433162743000@Atlassian.JIRA>
	<JIRA.12573418.1433162743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573418.1433162743000.58269.1486140120879@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358496#comment-13358496 ] 

RH Bugzilla Integration commented on WFCORE-725:
------------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1196686|https://bugzilla.redhat.com/show_bug.cgi?id=1196686] from VERIFIED to CLOSED

> Remove ClassIndex from the server module
> ----------------------------------------
>
>                 Key: WFCORE-725
>                 URL: https://issues.jboss.org/browse/WFCORE-725
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 2.0.0.Beta3
>
>
> ClassIndex is only used in a couple of places, and it is confusing to have two different indexes. It should be merged into ClassReflectionIndex.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:44:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4957) After failback backup prints
 warnings to log
In-Reply-To: <JIRA.12578411.1437135340000@Atlassian.JIRA>
References: <JIRA.12578411.1437135340000@Atlassian.JIRA>
	<JIRA.12578411.1437135340000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578411.1437135340000.58306.1486140240674@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358505#comment-13358505 ] 

RH Bugzilla Integration commented on WFLY-4957:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1159290|https://bugzilla.redhat.com/show_bug.cgi?id=1159290] from VERIFIED to CLOSED

> After failback backup prints warnings to log
> --------------------------------------------
>
>                 Key: WFLY-4957
>                 URL: https://issues.jboss.org/browse/WFLY-4957
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.0.0.Alpha5
>         Environment: Fedora 22
> openjdk 8
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>            Priority: Critical
>             Fix For: 10.0.0.CR5
>
>         Attachments: master.xml, slave.xml
>
>
> 15:34:59,123 WARN  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> 	at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> 	at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN  [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ: java.lang.IllegalStateException: Cannot access JMS Server, core server is not yet active
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> 	at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> 	at org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.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)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:45:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7372) Hibernate Scanner
 implementation class shouldn't leak application entity classes
In-Reply-To: <JIRA.12656712.1477401925000@Atlassian.JIRA>
References: <JIRA.12656712.1477401925000@Atlassian.JIRA>
	<JIRA.12656712.1477401925000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656712.1477401925000.58347.1486140301700@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358511#comment-13358511 ] 

RH Bugzilla Integration commented on WFLY-7372:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1390207|https://bugzilla.redhat.com/show_bug.cgi?id=1390207] from VERIFIED to CLOSED

> Hibernate Scanner implementation class shouldn't leak application entity classes
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-7372
>                 URL: https://issues.jboss.org/browse/WFLY-7372
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: JBoss AS7 7.2.0.Final, 10.1.0.Final
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:46:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4168) jdr.sh CommandLineMain does
 not run jdr on the application server
In-Reply-To: <JIRA.12559090.1418165724000@Atlassian.JIRA>
References: <JIRA.12559090.1418165724000@Atlassian.JIRA>
	<JIRA.12559090.1418165724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559090.1418165724000.58357.1486140360178@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358514#comment-13358514 ] 

RH Bugzilla Integration commented on WFLY-4168:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1195507|https://bugzilla.redhat.com/show_bug.cgi?id=1195507] from VERIFIED to CLOSED

> jdr.sh CommandLineMain does not run jdr on the application server
> -----------------------------------------------------------------
>
>                 Key: WFLY-4168
>                 URL: https://issues.jboss.org/browse/WFLY-4168
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 9.0.0.Beta1
>
>
> jdr.sh CommandLineMain does not run jdr on the application server
> JDR run via the CLI / Managemenet API -  runs the JDR report in the Application Server's JVM
> /subsystem=jdr:generate-jdr-report()
> Running jdr.sh / jdr.bat runs the JDR report in the JDR JVM
> jdr.sh / jdr.bat should run the JDR report in the Application Server's JVM if it is running.  If it is not running, then it should just collect the files that are available.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:47:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1998) Custom NameService by
 sun.net.spi.nameservice.provider.n doesn't work on WildFly
In-Reply-To: <JIRA.12655844.1476954323000@Atlassian.JIRA>
References: <JIRA.12655844.1476954323000@Atlassian.JIRA>
	<JIRA.12655844.1476954323000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655844.1476954323000.58364.1486140420598@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358515#comment-13358515 ] 

RH Bugzilla Integration commented on WFCORE-1998:
-------------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1395543|https://bugzilla.redhat.com/show_bug.cgi?id=1395543] from VERIFIED to CLOSED

> Custom NameService by sun.net.spi.nameservice.provider.n doesn't work on WildFly
> --------------------------------------------------------------------------------
>
>                 Key: WFCORE-1998
>                 URL: https://issues.jboss.org/browse/WFCORE-1998
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 2.2.0.Final
>            Reporter: Osamu Nagano
>            Assignee: Osamu Nagano
>              Labels: downstream_dependency
>             Fix For: 3.0.0.Alpha13
>
>         Attachments: nameserviceProviderTest.zip
>
>
> System property {{sun.net.spi.nameservice.provider.<n>}} allows a user to customize a NameService. It works on a standalone java, which is using JBoss Modules, if {{services="import"}} is added on sun.jdk module dependency and the sun.jdk module has the following additional dependencies.
> {code}
>                 <path name="sun/net/spi/nameservice"/>
>                 <path name="sun/net/spi/nameservice/dns"/>
> {code}
> Though it doesn't work as a web application which has the same module path and the same dependency in jboss-deployment-structure.xml.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:47:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7150) EJB injection with
 indirection via web.xml is ignored
In-Reply-To: <JIRA.12651000.1474373338000@Atlassian.JIRA>
References: <JIRA.12651000.1474373338000@Atlassian.JIRA>
	<JIRA.12651000.1474373338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651000.1474373338000.58377.1486140420933@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358517#comment-13358517 ] 

RH Bugzilla Integration commented on WFLY-7150:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1377705|https://bugzilla.redhat.com/show_bug.cgi?id=1377705] from VERIFIED to CLOSED

> EJB injection with indirection via web.xml is ignored
> -----------------------------------------------------
>
>                 Key: WFLY-7150
>                 URL: https://issues.jboss.org/browse/WFLY-7150
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Web (Undertow)
>            Reporter: Wolf-Dieter Fink
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Alpha1
>
>
> If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected.
> This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code.
> Reproducer can be found here:
> git at github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:47:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:47:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7140) Injection with @EJB is not
 working as expected with CDI (REST) beans
In-Reply-To: <JIRA.12650832.1474302652000@Atlassian.JIRA>
References: <JIRA.12650832.1474302652000@Atlassian.JIRA>
	<JIRA.12650832.1474302652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650832.1474302652000.58382.1486140421042@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358518#comment-13358518 ] 

RH Bugzilla Integration commented on WFLY-7140:
-----------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1377705|https://bugzilla.redhat.com/show_bug.cgi?id=1377705] from VERIFIED to CLOSED

> Injection with @EJB is not working as expected with CDI (REST) beans
> --------------------------------------------------------------------
>
>                 Key: WFLY-7140
>                 URL: https://issues.jboss.org/browse/WFLY-7140
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomas Remes
>             Fix For: 11.0.0.Alpha1
>
>
> The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet.
> @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne")
> is not working correct if used in a CDI Bean in the reproducer example.
> Reproducer can be found here:
>     git at github.com:wfink/jboss-eap-quickstarts.git
>     BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection
>     SubProject: ejb-multi-server  (used only a part of it to have a web-app and a ejb-app)
>                       see ejb-multi-server/README-reproducerEJB-injection



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 11:51:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 3 Feb 2017 11:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-893) Second security vault
 warning is displayed even if only one vault definition is present in the
 server configuration
In-Reply-To: <JIRA.12574614.1434011672000@Atlassian.JIRA>
References: <JIRA.12574614.1434011672000@Atlassian.JIRA>
	<JIRA.12574614.1434011672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574614.1434011672000.58427.1486140660265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/SECURITY-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358527#comment-13358527 ] 

RH Bugzilla Integration commented on SECURITY-893:
--------------------------------------------------

Petr Penicka <ppenicka at redhat.com> changed the Status of [bug 1389201|https://bugzilla.redhat.com/show_bug.cgi?id=1389201] from VERIFIED to CLOSED

> Second security vault warning is displayed even if only one vault definition is present in the server configuration
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-893
>                 URL: https://issues.jboss.org/browse/SECURITY-893
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX, Security-SPI
>    Affects Versions: PicketBox_4_1_0.Beta2
>            Reporter: Ivo Studensky
>            Assignee: Peter Skopek
>
> The BZ's description:
> I have only one vault configured in the standalone.xml but I see following warning message in the server log file after login attempt (bindCredentials login module option uses a vaulted password):
> {noformat}
> 09:10:58,854 WARN  [org.jboss.security] (http-/127.0.0.1:8080-1) PBOX000378: Attempt to create the second Security Vault [org.picketbox.plugins.vault.PicketBoxSecurityVault] is invalid. Only one Security Vault is supported. Change your configuration, please.
> {noformat}
> This issue is related to the previous fix for bz1055577, \[1\]. The problem needs to be fixed on EAP side in time of Security Subsystem configuration processing. Fix will be provided by bz1181457 \[2\].
> \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1055577
> \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1181457



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 12:03:00 2017
From: issues at jboss.org (Bhaskara Undi (JIRA))
Date: Fri, 3 Feb 2017 12:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7031) Redirect Port Fails to
 Redirect to 3rd Party HTTP Port
In-Reply-To: <JIRA.12648161.1472739224000@Atlassian.JIRA>
References: <JIRA.12648161.1472739224000@Atlassian.JIRA>
	<JIRA.12648161.1472739224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648161.1472739224000.58517.1486141380512@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358535#comment-13358535 ] 

Bhaskara Undi commented on WFLY-7031:
-------------------------------------

Hi Daniele,
Thank you very much for you fix. It is working for me. I really appreciate for help. Please put this configuration in the Wildfly10.1.0 documentation, if possible.


> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
>                 Key: WFLY-7031
>                 URL: https://issues.jboss.org/browse/WFLY-7031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Joe Carder
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected.  I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 12:14:00 2017
From: issues at jboss.org (Bhaskara Undi (JIRA))
Date: Fri, 3 Feb 2017 12:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7957) Redirecting to external ports
 such as 443 is not working
In-Reply-To: <JIRA.12672921.1485303423000@Atlassian.JIRA>
References: <JIRA.12672921.1485303423000@Atlassian.JIRA>
	<JIRA.12672921.1485303423000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672921.1485303423000.58553.1486142040166@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358543#comment-13358543 ] 

Bhaskara Undi commented on WFLY-7957:
-------------------------------------

Here I got the solution from Daniele Pirola 

Modify the ajp-listener specifying the attribute scheme like this:
{{ <ajp-listener name="ajp" socket-binding="ajp" *scheme="https"*/>}}
Now https call works fine and also redirect from http to https.

Please try to publish this solution/configuration in Wildfly10.1.0 documentation, if possible.

> Redirecting to external ports such as 443 is not working
> --------------------------------------------------------
>
>                 Key: WFLY-7957
>                 URL: https://issues.jboss.org/browse/WFLY-7957
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Sockets
>    Affects Versions: 10.1.0.Final
>         Environment: Windows Server 2012 R2 Standard, 64bit
>            Reporter: Bhaskara Undi
>            Assignee: Stuart Douglas
>
> 2017-01-24 10:57:17,812 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
> 	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.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60).........
> ------------------
> <server-identities>
>    <ssl>
>      <keystore path="edustgkeystore.jks" relative-to="jboss.server.config.dir" keystore-password="pass" alias="server"/>
>    </ssl>
> </server-identities>
> -----------------------------
>  <subsystem xmlns="urn:jboss:domain:undertow:3.1">
>     <buffer-cache name="default"/>
>        <server name="default-server">
>           <ajp-listener name="listen-ajp" socket-binding="ajp"/>
>           <http-listener name="default" socket-binding="http" redirect-socket="https-ext" enable-http2="true"/>
>           <https-listener name="https" socket-binding="https" security-realm="SSLRealm" enable-http2="true"/>
> -------------------------------
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
>    <socket-binding name="http" port="${jboss.http.port:8080}"/>
>    <socket-binding name="https" port="${jboss.https.port:8443}"/>



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 12:20:00 2017
From: issues at jboss.org (Bhaskara Undi (JIRA))
Date: Fri, 3 Feb 2017 12:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7031) Redirect Port Fails to
 Redirect to 3rd Party HTTP Port
In-Reply-To: <JIRA.12648161.1472739224000@Atlassian.JIRA>
References: <JIRA.12648161.1472739224000@Atlassian.JIRA>
	<JIRA.12648161.1472739224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648161.1472739224000.58592.1486142400676@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358547#comment-13358547 ] 

Bhaskara Undi commented on WFLY-7031:
-------------------------------------

Hi Daniele,

Thank you very much and it is working for me. I really appreciate your help.

Regards,
Bhaskara.

On Fri, Feb 3, 2017 at 12:52 AM, Daniele Pirola (JIRA) <issues at jboss.org>




-- 
Regards,
Bhaskara Undi
858-429-8345


> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
>                 Key: WFLY-7031
>                 URL: https://issues.jboss.org/browse/WFLY-7031
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.CR1
>            Reporter: Joe Carder
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected.  I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb  3 15:37:00 2017
From: issues at jboss.org (R Searls (JIRA))
Date: Fri, 3 Feb 2017 15:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8026) read-resource operation of
 jaxrs subsystem doesn't work if HttpServletDispatcher is used
In-Reply-To: <JIRA.12674922.1486154213000@Atlassian.JIRA>
References: <JIRA.12674922.1486154213000@Atlassian.JIRA>
	<JIRA.12674922.1486154213524@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674922.1486154213000.59228.1486154220104@Atlassian.JIRA>

R Searls created WFLY-8026:
------------------------------

             Summary: read-resource operation of jaxrs subsystem doesn't work if HttpServletDispatcher is used
                 Key: WFLY-8026
                 URL: https://issues.jboss.org/browse/WFLY-8026
             Project: WildFly
          Issue Type: Bug
          Components: REST
    Affects Versions: 10.1.0.Final
            Reporter: R Searls
            Assignee: R Searls
            Priority: Minor


There are a set of "Bootstap" classes which when present in the web.xml file require
jaxrs (i.e. resteasy) components to be configured using Resteasy Configuration Switches.
(see https://docs.jboss.org/resteasy/docs/3.0.4.Final/userguide/html/Installation_Configuration.html#d4e125 )
Adding the following switch to the web.xml should solve the issue. 

2 resteasy config switches need to be added dynamically when a jaxrs Application subclass  is found in the web.xml file.  

This addresses the issue flagged in https://issues.jboss.org/browse/JBEAP-8064




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb  4 13:32:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 4 Feb 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2264) Missing capability tab
 completion on object type attributes
In-Reply-To: <JIRA.12674939.1486233065000@Atlassian.JIRA>
References: <JIRA.12674939.1486233065000@Atlassian.JIRA>
	<JIRA.12674939.1486233065679@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674939.1486233065000.59982.1486233120268@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2264:
----------------------------------------

             Summary: Missing capability tab completion on object type attributes
                 Key: WFCORE-2264
                 URL: https://issues.jboss.org/browse/WFCORE-2264
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 3.0.0.Alpha22
         Environment: Reproducible using current WildFly master
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha23


The following command is valid: -

{{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}

However tab completion is not possible to discover the available capabilities for the value.

I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.

(I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb  4 13:32:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 4 Feb 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2264) Missing capability tab
 completion on object type attributes
In-Reply-To: <JIRA.12674939.1486233066000@Atlassian.JIRA>
References: <JIRA.12674939.1486233066000@Atlassian.JIRA>
	<JIRA.12674939.1486233066000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674939.1486233066000.59987.1486233120421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFCORE-2264:
----------------------------------------

    Assignee:     (was: Darran Lofthouse)


> Missing capability tab completion on object type attributes
> -----------------------------------------------------------
>
>                 Key: WFCORE-2264
>                 URL: https://issues.jboss.org/browse/WFCORE-2264
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha22
>         Environment: Reproducible using current WildFly master
>            Reporter: Darran Lofthouse
>             Fix For: 3.0.0.Alpha23
>
>
> The following command is valid: -
> {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}
> However tab completion is not possible to discover the available capabilities for the value.
> I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.
> (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb  4 13:38:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 4 Feb 2017 13:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2264) Missing capability tab
 completion on object type attributes
In-Reply-To: <JIRA.12674939.1486233066000@Atlassian.JIRA>
References: <JIRA.12674939.1486233066000@Atlassian.JIRA>
	<JIRA.12674939.1486233066000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674939.1486233066000.59996.1486233480259@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFCORE-2264:
----------------------------------------

    Assignee: Jean-Francois Denise


> Missing capability tab completion on object type attributes
> -----------------------------------------------------------
>
>                 Key: WFCORE-2264
>                 URL: https://issues.jboss.org/browse/WFCORE-2264
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha22
>         Environment: Reproducible using current WildFly master
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>
> The following command is valid: -
> {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}
> However tab completion is not possible to discover the available capabilities for the value.
> I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.
> (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb  4 14:50:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 4 Feb 2017 14:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-920) Disable testing of PKCS#12
 CredentialStore due to CI failures
In-Reply-To: <JIRA.12674942.1486237796000@Atlassian.JIRA>
References: <JIRA.12674942.1486237796000@Atlassian.JIRA>
	<JIRA.12674942.1486237796752@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674942.1486237796000.60014.1486237800174@Atlassian.JIRA>

Darran Lofthouse created ELY-920:
------------------------------------

             Summary: Disable testing of PKCS#12 CredentialStore due to CI failures
                 Key: ELY-920
                 URL: https://issues.jboss.org/browse/ELY-920
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Beta23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb  4 21:30:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Sat, 4 Feb 2017 21:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2265) Subsystem transformation
 tests throw ISE during resource transformation if resource has override
 registrations
In-Reply-To: <JIRA.12674945.1486261763000@Atlassian.JIRA>
References: <JIRA.12674945.1486261763000@Atlassian.JIRA>
	<JIRA.12674945.1486261763906@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674945.1486261763000.60032.1486261800078@Atlassian.JIRA>

Paul Ferraro created WFCORE-2265:
------------------------------------

             Summary: Subsystem transformation tests throw ISE during resource transformation if resource has override registrations
                 Key: WFCORE-2265
                 URL: https://issues.jboss.org/browse/WFCORE-2265
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Test Suite
    Affects Versions: 3.0.0.Alpha22
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


The problematic logic looks to in:
org.jboss.as.subsystem.test.TransformationUtils.modelToResource(...), which will copy resource definition with wildcard overrides into the model twice.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 05:06:00 2017
From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=)
Date: Sun, 5 Feb 2017 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7987) Remove operations should warn
 the user if the resource has any dependents
In-Reply-To: <JIRA.12673524.1485621086000@Atlassian.JIRA>
References: <JIRA.12673524.1485621086000@Atlassian.JIRA>
	<JIRA.12673524.1485621086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673524.1485621086000.60055.1486289160243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13358701#comment-13358701 ] 

Guillermo Gonz?lez de Ag?ero commented on WFLY-7987:
----------------------------------------------------

Hi [~brian.stansberry]. My original report on this issue was based on a wrong assumption that services = capabilities, so I think I'd better close this. For the new capabilities requests, I understand I should open one issue for each one, so it can be correctly categorized, right? I want to confirm just to prevent spamming Jira with too much issues. Thanks!

> 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: Stuart Douglas
>
> 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  Sun Feb  5 09:04:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2249) ObjectTypeValidator only
 validates fields the user provides
In-Reply-To: <JIRA.12673993.1485882653000@Atlassian.JIRA>
References: <JIRA.12673993.1485882653000@Atlassian.JIRA>
	<JIRA.12673993.1485882653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673993.1485882653000.60088.1486303443327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2249:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> ObjectTypeValidator only validates fields the user provides
> -----------------------------------------------------------
>
>                 Key: WFCORE-2249
>                 URL: https://issues.jboss.org/browse/WFCORE-2249
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha24
>
>
> This in ObjectTypeValidator is wrong:
> {code}
>     @Override
>     public void validateParameter(final String parameterName, final ModelNode value) throws OperationFailedException {
>         super.validateParameter(parameterName, value);
>         if (value.isDefined()) {
>             for (String key : value.keys()) {
>                 if (allowedValues.containsKey(key)) {
>                     allowedValues.get(key).getValidator().validateParameter(key, value.get(key));
>                 } else {
>                     throw ROOT_LOGGER.invalidKeyForObjectType(key, parameterName);
>                 }
>             }
>         }
>     }
> {code}
> 1) It only iterates over the keys in 'value' so if value is missing any required fields that isn't detected.
> 2) It's not really appropriate to reject keys that are not part of the definition. The management code is meant to be forgiving in such cases.
> For now I think I'll just focus on #1. It's debatable whether being forgiving is really ideal in general, and since this particular bit of unforgivingness has been around since at least 2012 I think I'll leave it alone.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2264) Missing capability tab
 completion on object type attributes
In-Reply-To: <JIRA.12674939.1486233066000@Atlassian.JIRA>
References: <JIRA.12674939.1486233066000@Atlassian.JIRA>
	<JIRA.12674939.1486233066000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674939.1486233066000.60085.1486303443281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2264:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> Missing capability tab completion on object type attributes
> -----------------------------------------------------------
>
>                 Key: WFCORE-2264
>                 URL: https://issues.jboss.org/browse/WFCORE-2264
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha22
>         Environment: Reproducible using current WildFly master
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha24
>
>
> The following command is valid: -
> {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}
> However tab completion is not possible to discover the available capabilities for the value.
> I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.
> (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.60100.1486303443791@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha24, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Sun Feb  5 09:04:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.60107.1486303444093@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.60096.1486303443566@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.60124.1486303444621@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:04 -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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.60114.1486303444338@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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  Sun Feb  5 09:04:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.60133.1486303444874@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.60140.1486303445003@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2059) Deprecate management role
	mappings
In-Reply-To: <JIRA.12664348.1480440978000@Atlassian.JIRA>
References: <JIRA.12664348.1480440978000@Atlassian.JIRA>
	<JIRA.12664348.1480440978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664348.1480440978000.60143.1486303445074@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2059:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> Deprecate management role mappings
> ----------------------------------
>
>                 Key: WFCORE-2059
>                 URL: https://issues.jboss.org/browse/WFCORE-2059
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha24
>
>
> The Elytron SecurityDomain becomes the common point where policy information such as role mapping should be handled.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2025) CLI SSLContext Priority
In-Reply-To: <JIRA.12662781.1479732593000@Atlassian.JIRA>
References: <JIRA.12662781.1479732593000@Atlassian.JIRA>
	<JIRA.12662781.1479732593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662781.1479732593000.60159.1486303445519@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2025:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> CLI SSLContext Priority
> -----------------------
>
>                 Key: WFCORE-2025
>                 URL: https://issues.jboss.org/browse/WFCORE-2025
>             Project: WildFly Core
>          Issue Type: Task
>          Components: CLI, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha24
>
>
> We have three different places an SSLContext could come from for the CLI: -
> # CLI Configuration
> # AuthenticationClient Configuration
> # Default interactive SSLContext
> We need to ensure they are prioritised as above.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.60178.1486303446034@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1964:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha24
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.60170.1486303445767@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha24
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.60167.1486303445691@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1963) Clean up the 'TODO Elytron'
	issues.
In-Reply-To: <JIRA.12660284.1478632505000@Atlassian.JIRA>
References: <JIRA.12660284.1478632505000@Atlassian.JIRA>
	<JIRA.12660284.1478632505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660284.1478632505000.60182.1486303446104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1963:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> Clean up the 'TODO Elytron' issues.
> -----------------------------------
>
>                 Key: WFCORE-1963
>                 URL: https://issues.jboss.org/browse/WFCORE-1963
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha24
>
>
> A few classes have 'TODO Elytron' comments that need addressing.
> Current List: -
> {noformat}
> ./core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java
> ./jmx/src/test/java/org/jboss/as/jmx/rbac/JmxRbacTestCase.java
> ./remoting/subsystem/src/main/java/org/jboss/as/remoting/RemotingHttpUpgradeService.java
> ./remoting/subsystem/src/main/java/org/jboss/as/remoting/AbstractStreamServerService.java
> ./testsuite/standalone/src/test/java/org/wildfly/core/test/standalone/mgmt/api/core/ConfigurationChangesHistoryTestCase.java
> ./host-controller/src/main/java/org/jboss/as/domain/controller/plan/AbstractServerGroupRolloutTask.java
> ./controller/src/main/java/org/jboss/as/controller/remote/TransactionalProtocolOperationHandler.java
> ./controller/src/main/java/org/jboss/as/controller/ParallelBootOperationStepHandler.java
> ./controller/src/main/java/org/jboss/as/controller/access/management/ManagementSecurityIdentitySupplier.java
> ./server/src/main/java/org/jboss/as/server/mgmt/domain/HostControllerConnectionService.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/UserDomainCallbackHandler.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/WhoAmIOperation.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/PlugInAuthenticationCallbackHandler.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/JaasCallbackHandler.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/KerberosCallbackHandler.java
> ./domain-management/src/main/java/org/jboss/as/domain/management/security/ClientCertCallbackHandler.java
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.60187.1486303446281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1956) Audit logging post
 migration to WildFly Elytron
In-Reply-To: <JIRA.12660204.1478617658000@Atlassian.JIRA>
References: <JIRA.12660204.1478617658000@Atlassian.JIRA>
	<JIRA.12660204.1478617658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660204.1478617658000.60194.1486303446527@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1956:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> Audit logging post migration to WildFly Elytron
> -----------------------------------------------
>
>                 Key: WFCORE-1956
>                 URL: https://issues.jboss.org/browse/WFCORE-1956
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha24
>
>
> Also re-enable the following test: -
> * org.jboss.as.test.integration.domain.suites.AuditLogTestCase



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.60201.1486303446753@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.60207.1486303446934@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.60215.1486303447194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:07 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.60226.1486303447428@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Alpha24
>
>         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  Sun Feb  5 09:04:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.60241.1486303447801@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:07 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.60235.1486303447656@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>         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  Sun Feb  5 09:04:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.60245.1486303448014@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.60252.1486303448489@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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.<init>(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  Sun Feb  5 09:04:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.60258.1486303448719@Atlassian.JIRA>


     [ 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.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>
> 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  Sun Feb  5 09:04:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 5 Feb 2017 09:04:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.60151.1486303445310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Alpha24
                       (was: 3.0.0.Alpha23)


> 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.Alpha24
>
>         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  Sun Feb  5 10:36:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 5 Feb 2017 10:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2059) Deprecate management role
	mappings
In-Reply-To: <JIRA.12664348.1480440978000@Atlassian.JIRA>
References: <JIRA.12664348.1480440978000@Atlassian.JIRA>
	<JIRA.12664348.1480440978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664348.1480440978000.60375.1486308960380@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-2059.
--------------------------------------
    Resolution: Deferred


Marking as differed, either management role mapping or Elytron role mapping can now be used.

Rather than deprecating this option another option is to support permission checks being handled within Elytron instead,

> Deprecate management role mappings
> ----------------------------------
>
>                 Key: WFCORE-2059
>                 URL: https://issues.jboss.org/browse/WFCORE-2059
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Alpha24
>
>
> The Elytron SecurityDomain becomes the common point where policy information such as role mapping should be handled.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 11:00:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 5 Feb 2017 11:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2266) Ensure remaining legacy
 realm components have Elytron wrappers.
In-Reply-To: <JIRA.12674967.1486310364000@Atlassian.JIRA>
References: <JIRA.12674967.1486310364000@Atlassian.JIRA>
	<JIRA.12674967.1486310364887@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674967.1486310364000.60398.1486310400373@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2266:
----------------------------------------

             Summary: Ensure remaining legacy realm components have Elytron wrappers.
                 Key: WFCORE-2266
                 URL: https://issues.jboss.org/browse/WFCORE-2266
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 12:00:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 5 Feb 2017 12:00:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314004000@Atlassian.JIRA>
References: <JIRA.12674971.1486314004000@Atlassian.JIRA>
	<JIRA.12674971.1486314004722@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314004000.60453.1486314006353@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2267:
----------------------------------------

             Summary: 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.Alpha24


Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 17:30:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 5 Feb 2017 17:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8028) Appclient TCK issues after
 Elytron invocation merge
In-Reply-To: <JIRA.12674976.1486333777000@Atlassian.JIRA>
References: <JIRA.12674976.1486333777000@Atlassian.JIRA>
	<JIRA.12674976.1486333777189@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674976.1486333777000.60511.1486333800224@Atlassian.JIRA>

Stuart Douglas created WFLY-8028:
------------------------------------

             Summary: Appclient TCK issues after Elytron invocation merge
                 Key: WFLY-8028
                 URL: https://issues.jboss.org/browse/WFLY-8028
             Project: WildFly
          Issue Type: Bug
          Components: Application Client, EJB
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb  5 17:30:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 5 Feb 2017 17:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8027) Appclient TCK issues after
 Elytron invocation merge
In-Reply-To: <JIRA.12674975.1486333754000@Atlassian.JIRA>
References: <JIRA.12674975.1486333754000@Atlassian.JIRA>
	<JIRA.12674975.1486333754471@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674975.1486333754000.60509.1486333800186@Atlassian.JIRA>

Stuart Douglas created WFLY-8027:
------------------------------------

             Summary: Appclient TCK issues after Elytron invocation merge
                 Key: WFLY-8027
                 URL: https://issues.jboss.org/browse/WFLY-8027
             Project: WildFly
          Issue Type: Bug
          Components: Application Client, EJB
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 03:03:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 6 Feb 2017 03:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8029) Servlet lifecycle tests fail
 with security managed
In-Reply-To: <JIRA.12674984.1486368175000@Atlassian.JIRA>
References: <JIRA.12674984.1486368175000@Atlassian.JIRA>
	<JIRA.12674984.1486368175818@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674984.1486368175000.60846.1486368180191@Atlassian.JIRA>

Jan Tymel created WFLY-8029:
-------------------------------

             Summary: Servlet lifecycle tests fail with security managed
                 Key: WFLY-8029
                 URL: https://issues.jboss.org/browse/WFLY-8029
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Jan Tymel


Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)

*org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 55 more
{code}

*org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 57 more
{code}

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 56 more
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 03:31:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 6 Feb 2017 03:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.60916.1486369860427@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-903:
-----------------------------
    Description: 
In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.

Most important part of ldif for reproduction is following:
{code}
dn: cn=R1,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R1
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the R1 group

dn: cn=R2,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R2
member: uid=jduke,ou=People,dc=jboss,dc=org
member: cn=R1,ou=Roles,dc=jboss,dc=org
description: the R2 group

dn: cn=R3,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R3
member: cn=R2,ou=Roles,dc=jboss,dc=org
description: the R3 group
{code}
User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).

The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).

  was:
In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.

Most important part of ldif for reproduction is following:
{code}
dn: cn=R1,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R1
member: uid=jduke,ou=People,dc=jboss,dc=org
description: the R1 group

dn: cn=R2,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R2
member: uid=jduke,ou=People,dc=jboss,dc=org
member: cn=R1,ou=Roles,dc=jboss,dc=org
description: the R2 group

dn: cn=R3,ou=Roles,dc=jboss,dc=org
objectclass: top
objectclass: groupOfNames
cn: R3
member: cn=R2,ou=Roles,dc=jboss,dc=org
description: the R3 group
{code}
User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).



> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
> The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 03:35:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 6 Feb 2017 03:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8029) Servlet lifecycle tests fail
 with security manager
In-Reply-To: <JIRA.12674984.1486368176000@Atlassian.JIRA>
References: <JIRA.12674984.1486368176000@Atlassian.JIRA>
	<JIRA.12674984.1486368176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674984.1486368176000.60927.1486370100200@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFLY-8029:
----------------------------
    Summary: Servlet lifecycle tests fail with security manager  (was: Servlet lifecycle tests fail with security managed)


> Servlet lifecycle tests fail with security manager
> --------------------------------------------------
>
>                 Key: WFLY-8029
>                 URL: https://issues.jboss.org/browse/WFLY-8029
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>
> Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)
> *org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 55 more
> {code}
> *org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
> 	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
> 	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 57 more
> {code}
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
> 	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 03:38:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 6 Feb 2017 03:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8029) Servlet lifecycle tests fail
 with security manager
In-Reply-To: <JIRA.12674984.1486368176000@Atlassian.JIRA>
References: <JIRA.12674984.1486368176000@Atlassian.JIRA>
	<JIRA.12674984.1486368176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674984.1486368176000.60946.1486370280216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFLY-8029:
----------------------------
    Description: 
Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)

*org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 55 more
{code}

*org.jboss.as.test.integration.ee.lifecycle.servlet.ListenerLifecycleCallbackInterceptionTestCase#testListenerPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 57 more
{code}

*org.jboss.as.test.integration.ee.lifecycle.servlet.ServletLifecycleCallbackInterceptionTestCase#testServletPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 56 more
{code}

  was:
Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)

*org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 55 more
{code}

*org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 57 more
{code}

# export MYTESTIP_1=192.168.1.50
# sudo ifconfig em1:0 192.168.1.50
# ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1

{code}
[org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
	... 56 more
{code}



> Servlet lifecycle tests fail with security manager
> --------------------------------------------------
>
>                 Key: WFLY-8029
>                 URL: https://issues.jboss.org/browse/WFLY-8029
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>
> Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)
> *org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 55 more
> {code}
> *org.jboss.as.test.integration.ee.lifecycle.servlet.ListenerLifecycleCallbackInterceptionTestCase#testListenerPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
> 	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
> 	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 57 more
> {code}
> *org.jboss.as.test.integration.ee.lifecycle.servlet.ServletLifecycleCallbackInterceptionTestCase#testServletPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
> 	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 05:39:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 05:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-18) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673939.1485872724000@Atlassian.JIRA>
References: <JIRA.12673939.1485872724000@Atlassian.JIRA>
	<JIRA.12673939.1485872724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673939.1485872724000.61742.1486377540277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-18:
-------------------------------------
    Description: 
Middleware Provider running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS&tab=properties

  was:Middleware Provider running inside and outside of Openshift.



> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-18
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-18
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>            Priority: Blocker
>              Labels: hawkular-qe-manual
>
> Middleware Provider running inside and outside of Openshift.
> Manual test case runs were created:
> For case when MM runs Outside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS
> For case when MM runs Inside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS&tab=properties



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 05:46:02 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 05:46:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-18) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673939.1485872724000@Atlassian.JIRA>
References: <JIRA.12673939.1485872724000@Atlassian.JIRA>
	<JIRA.12673939.1485872724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673939.1485872724000.61839.1486377962024@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-18:
-------------------------------------
    Description: 
Middleware Provider running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS

  was:
Middleware Provider running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS&tab=properties



> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-18
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-18
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>            Priority: Blocker
>              Labels: hawkular-qe-manual
>
> Middleware Provider running inside and outside of Openshift.
> Manual test case runs were created:
> For case when MM runs Outside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS
> For case when MM runs Inside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 06:09:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 06:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-18) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673939.1485872724000@Atlassian.JIRA>
References: <JIRA.12673939.1485872724000@Atlassian.JIRA>
	<JIRA.12673939.1485872724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673939.1485872724000.62000.1486379340639@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-18:
-------------------------------------
    Description: 
Middleware Manager running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS

  was:
Middleware Provider running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS



> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-18
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-18
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>            Priority: Blocker
>              Labels: hawkular-qe-manual
>
> Middleware Manager running inside and outside of Openshift.
> Manual test case runs were created:
> For case when MM runs Outside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS
> For case when MM runs Inside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-160%20-%20OpenShift%20EAP%206%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 06:09:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 06:09:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-16) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673935.1485872034000@Atlassian.JIRA>
References: <JIRA.12673935.1485872034000@Atlassian.JIRA>
	<JIRA.12673935.1485872034000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673935.1485872034000.62019.1486379341133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-16:
-------------------------------------
    Description: 
Middleware Manager running inside and outside of Openshift.

Manual test case runs were created:

For case when MM runs Outside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-159%20-%20OpenShift%20EAP%207%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS

For case when MM runs Inside OS
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-159%20-%20OpenShift%20EAP%207%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS

  was:Middleware Provider running inside and outside of Openshift.



> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-16
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-16
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>            Priority: Blocker
>              Labels: hawkular-qe-manual
>
> Middleware Manager running inside and outside of Openshift.
> Manual test case runs were created:
> For case when MM runs Outside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-159%20-%20OpenShift%20EAP%207%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Outside%20OS
> For case when MM runs Inside OS
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-159%20-%20OpenShift%20EAP%207%20Docker%20image%20with%20Hawkular%20Agent%20-%20MM%20Inside%20OS



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 06:15:00 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 6 Feb 2017 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4539) logging statement to trace
 remoting heartbeat
In-Reply-To: <JIRA.12568820.1429524342000@Atlassian.JIRA>
References: <JIRA.12568820.1429524342000@Atlassian.JIRA>
	<JIRA.12568820.1429524342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568820.1429524342000.62062.1486379700559@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga resolved WFLY-4539.
--------------------------------
    Resolution: Done


Resolved by the upgrade to remoting 5.0.0.Beta13 that happened some time ago

> 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  Mon Feb  6 07:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-921) Elytron FORM authentication
 failing if TRACE is enabled.
In-Reply-To: <JIRA.12673133.1485426006000@Atlassian.JIRA>
References: <JIRA.12673133.1485426006000@Atlassian.JIRA>
	<JIRA.12673133.1485426006000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673133.1485426006000.63031.1486385040357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-7978 to ELY-921:
--------------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-921  (was: WFLY-7978)
          Component/s: HTTP
                           (was: Security)
    Affects Version/s: 1.1.0.Beta22
                           (was: 11.0.0.Alpha1)


> Elytron FORM authentication failing if TRACE is enabled.
> --------------------------------------------------------
>
>                 Key: ELY-921
>                 URL: https://issues.jboss.org/browse/ELY-921
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta22
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>         Attachments: secured-webapp.war.zip
>
>
> NPE occures during FORM authentication when TRACE logging is enabled.  
> {code}
> 11:02:55,488 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/: java.lang.NullPointerException
> 	at org.wildfly.elytron.web.undertow.server.ElytronHttpExchange$4.getID(ElytronHttpExchange.java:401)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptReAuthentication(FormAuthenticationMechanism.java:228)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:99)
> 	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)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	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.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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	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:210)
> 	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}
> {code:java|title=FormAuthenticationMechanism.java}
>         if (log.isTraceEnabled()) {
>             if (getSessionScope(request, false) != null) {
>                 log.tracef("Trying to re-authenticate session %s using FormAuthenticationMechanism. Request URI: [%s], Context path: [%s]",
>                         getSessionScope(request, false).getID(), request.getRequestURI(), this.contextPath);
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 07:47:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7996) Default Elytron subsystem
 configuration doesn't support local authentication in ApplicationRealm
In-Reply-To: <JIRA.12673705.1485788656000@Atlassian.JIRA>
References: <JIRA.12673705.1485788656000@Atlassian.JIRA>
	<JIRA.12673705.1485788656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673705.1485788656000.63059.1486385220969@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7996:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7996
>                 URL: https://issues.jboss.org/browse/WFLY-7996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> 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  Mon Feb  6 07:47:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 07:47:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7949) Missing a simple way to
	enable Elytron
In-Reply-To: <JIRA.12672668.1485252168000@Atlassian.JIRA>
References: <JIRA.12672668.1485252168000@Atlassian.JIRA>
	<JIRA.12672668.1485252168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672668.1485252168000.63079.1486385221559@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7949:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Missing a simple way to enable Elytron
> --------------------------------------
>
>                 Key: WFLY-7949
>                 URL: https://issues.jboss.org/browse/WFLY-7949
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: user_experience
>
> There should be a simple way (e.g. a CLI script provided with AS distribution) which would enable the Elytron in subsystems. As the {{standalone-elytron.xml}} profile was removed now, users don't have a one-step way to use the Elytron.
> I've put some CLI commands together for my testing, but I doubt this is a complete solution:
> http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 07:49:20 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Mon, 6 Feb 2017 07:49:20 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-918) Allow HTTP mechanisms to decide
 if response should be sent when authentication is in progress
In-Reply-To: <JIRA.12674807.1486132276000@Atlassian.JIRA>
References: <JIRA.12674807.1486132276000@Atlassian.JIRA>
	<JIRA.12674807.1486132276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674807.1486132276000.63405.1486385360914@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor closed ELY-918.
--------------------------
    Resolution: Rejected


> Allow HTTP mechanisms to decide if response should be sent when authentication is in progress
> ---------------------------------------------------------------------------------------------
>
>                 Key: ELY-918
>                 URL: https://issues.jboss.org/browse/ELY-918
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Currently, mechanisms are not allowed to decide if a challenge should be sent or not when processing a request to path where authentication is not required.
> Currently, we always write to the response regardless if authentication if required or not, making impossible to mechanisms decide what you do in cases where a request is a for a non-protected resource and an authentication challenge should not be sent.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:02:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 08:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-921) Elytron FORM authentication
 failing if TRACE is enabled.
In-Reply-To: <JIRA.12673133.1485426006000@Atlassian.JIRA>
References: <JIRA.12673133.1485426006000@Atlassian.JIRA>
	<JIRA.12673133.1485426006000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673133.1485426006000.63650.1486386120677@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-921:
---------------------------------
    Fix Version/s: 1.1.0.Beta23


> Elytron FORM authentication failing if TRACE is enabled.
> --------------------------------------------------------
>
>                 Key: ELY-921
>                 URL: https://issues.jboss.org/browse/ELY-921
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta22
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta23
>
>         Attachments: secured-webapp.war.zip
>
>
> NPE occures during FORM authentication when TRACE logging is enabled.  
> {code}
> 11:02:55,488 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/: java.lang.NullPointerException
> 	at org.wildfly.elytron.web.undertow.server.ElytronHttpExchange$4.getID(ElytronHttpExchange.java:401)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptReAuthentication(FormAuthenticationMechanism.java:228)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:99)
> 	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)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	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.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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	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:210)
> 	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}
> {code:java|title=FormAuthenticationMechanism.java}
>         if (log.isTraceEnabled()) {
>             if (getSessionScope(request, false) != null) {
>                 log.tracef("Trying to re-authenticate session %s using FormAuthenticationMechanism. Request URI: [%s], Context path: [%s]",
>                         getSessionScope(request, false).getID(), request.getRequestURI(), this.contextPath);
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:02:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 08:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-922) Elytron ldap-realm does not
 handle loops in referrals
In-Reply-To: <JIRA.12675046.1486386065000@Atlassian.JIRA>
References: <JIRA.12675046.1486386065000@Atlassian.JIRA>
	<JIRA.12675046.1486386065591@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675046.1486386065000.63646.1486386120502@Atlassian.JIRA>

Jan Kalina created ELY-922:
------------------------------

             Summary: Elytron ldap-realm does not handle loops in referrals
                 Key: ELY-922
                 URL: https://issues.jboss.org/browse/ELY-922
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
    Affects Versions: 1.1.0.Beta21
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Critical


According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".

When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.

[1] http://tools.ietf.org/html/rfc4511#section-4.1.10



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:02:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 08:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-896) NPE in server log if client's
 password is null
In-Reply-To: <JIRA.12673000.1485351216000@Atlassian.JIRA>
References: <JIRA.12673000.1485351216000@Atlassian.JIRA>
	<JIRA.12673000.1485351216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673000.1485351216000.63663.1486386121320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-896:
---------------------------------
    Fix Version/s: 1.1.0.Beta23


> NPE in server log if client's password is null 
> -----------------------------------------------
>
>                 Key: ELY-896
>                 URL: https://issues.jboss.org/browse/ELY-896
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Passwords
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta23
>
>
> If standalone JMS client creates connection with username and password where password is {{null}} like:
> {code}
> connectionFactory.createConnection("admin", null);
> {code}
> then server logs NPE:
> {code}
> 13:24:10,567 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: java.lang.NullPointerException
> 	at java.util.Arrays.fill(Arrays.java:2951) [rt.jar:1.8.0_71]
> 	at org.wildfly.security.evidence.PasswordGuessEvidence.destroy(PasswordGuessEvidence.java:53) [wildfly-elytron-1.1.0.Beta16.jar:1.1.0.Beta16]
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:107)
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
> 	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
> 	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}
> Server should log the same error as if wrong password is provided:
> {code}
> 13:23:38,713 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> 	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> 	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:02:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 08:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8030) Elytron ldap-realm does not
 handle loops in referrals
In-Reply-To: <JIRA.12675046.1486386066000@Atlassian.JIRA>
References: <JIRA.12675046.1486386066000@Atlassian.JIRA>
	<JIRA.12675046.1486386066000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675046.1486386066000.63657.1486386121076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved ELY-922 to WFLY-8030:
--------------------------------------

              Project: WildFly  (was: WildFly Elytron)
                  Key: WFLY-8030  (was: ELY-922)
          Component/s: Security
                           (was: Realms)
    Affects Version/s:     (was: 1.1.0.Beta21)


> Elytron ldap-realm does not handle loops in referrals
> -----------------------------------------------------
>
>                 Key: WFLY-8030
>                 URL: https://issues.jboss.org/browse/WFLY-8030
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.".
> When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server.
> [1] http://tools.ietf.org/html/rfc4511#section-4.1.10



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:16:02 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Mon, 6 Feb 2017 08:16:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-923) Elytron LDAP caching realm
 should cache attributes and credentials
In-Reply-To: <JIRA.12675054.1486386810000@Atlassian.JIRA>
References: <JIRA.12675054.1486386810000@Atlassian.JIRA>
	<JIRA.12675054.1486386810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675054.1486386810000.63845.1486386962202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek moved JBEAP-8680 to ELY-923:
-----------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-923  (was: JBEAP-8680)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Realms
                           (was: Security)
    Affects Version/s: 1.1.0.Beta21
                           (was: 7.1.0.DR11)


> 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
>            Priority: Blocker
>
> 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  Mon Feb  6 08:35:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 6 Feb 2017 08:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8031) Provide an option to
 configure Weld global thread pool size
In-Reply-To: <JIRA.12675060.1486388049000@Atlassian.JIRA>
References: <JIRA.12675060.1486388049000@Atlassian.JIRA>
	<JIRA.12675060.1486388049896@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675060.1486388049000.63983.1486388100532@Atlassian.JIRA>

Martin Kouba created WFLY-8031:
----------------------------------

             Summary: Provide an option to configure Weld global thread pool size 
                 Key: WFLY-8031
                 URL: https://issues.jboss.org/browse/WFLY-8031
             Project: WildFly
          Issue Type: Feature Request
          Components: CDI / Weld
            Reporter: Martin Kouba
            Assignee: Martin Kouba
            Priority: Minor


As mentioned in https://issues.jboss.org/browse/WFLY-4653 it could be useful to have an option to configure Weld thread pool size e.g. in standalone configuration. Currently the size of the thread pool is hardcoded at https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/services/bootstrap/WeldExecutorServices.java#L51
However note that this thread pool is used ONLY during the bootstrap of the Weld container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:40:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 6 Feb 2017 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6513) Provide an option to
 configure Weld global thread pool size
In-Reply-To: <JIRA.12614604.1460466475000@Atlassian.JIRA>
References: <JIRA.12614604.1460466475000@Atlassian.JIRA>
	<JIRA.12614604.1460466475000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614604.1460466475000.64030.1486388400353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-6513:
-------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> Provide an option to configure Weld global thread pool size 
> ------------------------------------------------------------
>
>                 Key: WFLY-6513
>                 URL: https://issues.jboss.org/browse/WFLY-6513
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CDI / Weld
>            Reporter: Tomas Remes
>            Assignee: Martin Kouba
>            Priority: Minor
>
> As mentioned in https://issues.jboss.org/browse/WFLY-4653 it could be useful to have an option to configure Weld thread pool size e.g. in standalone configuration. Currently the size of the thread pool is hardcoded at https://github.com/wildfly/wildfly/blob/master/weld/src/main/java/org/jboss/as/weld/services/bootstrap/WeldExecutorServices.java#L51
> However note that this thread pool is used ONLY during the bootstrap of the Weld container.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 08:44:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 08:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675062.1486388587000@Atlassian.JIRA>
References: <JIRA.12675062.1486388587000@Atlassian.JIRA>
	<JIRA.12675062.1486388587640@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675062.1486388587000.64058.1486388640423@Atlassian.JIRA>

Tomas Hofman created JBJCA-1338:
-----------------------------------

             Summary: 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
    Affects Versions: 1.2.7.Final
            Reporter: 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 Feb  6 08:45:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1339) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675064.1486388665000@Atlassian.JIRA>
References: <JIRA.12675064.1486388665000@Atlassian.JIRA>
	<JIRA.12675064.1486388665936@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675064.1486388665000.64069.1486388700277@Atlassian.JIRA>

Tomas Hofman created JBJCA-1339:
-----------------------------------

             Summary: CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
                 Key: JBJCA-1339
                 URL: https://issues.jboss.org/browse/JBJCA-1339
             Project: IronJacamar
          Issue Type: Bug
    Affects Versions: 1.2.7.Final
            Reporter: 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 Feb  6 08:46:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675064.1486388666000@Atlassian.JIRA>
References: <JIRA.12675064.1486388666000@Atlassian.JIRA>
	<JIRA.12675064.1486388666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675064.1486388666000.64076.1486388760326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman updated WFLY-8032:
-------------------------------
    Component/s: JCA


> 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
>
> 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 Feb  6 08:46:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675064.1486388666000@Atlassian.JIRA>
References: <JIRA.12675064.1486388666000@Atlassian.JIRA>
	<JIRA.12675064.1486388666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675064.1486388666000.64072.1486388760197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman moved JBJCA-1339 to WFLY-8032:
-------------------------------------------

              Project: WildFly  (was: IronJacamar)
                  Key: WFLY-8032  (was: JBJCA-1339)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 10.1.0.Final
                           (was: 1.2.7.Final)


> 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
>    Affects Versions: 10.1.0.Final
>            Reporter: 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 Feb  6 08:47:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675064.1486388666000@Atlassian.JIRA>
References: <JIRA.12675064.1486388666000@Atlassian.JIRA>
	<JIRA.12675064.1486388666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675064.1486388666000.64085.1486388820986@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned WFLY-8032:
----------------------------------

    Assignee: Stefano Maestri


> 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: Stefano Maestri
>
> 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 Feb  6 08:52:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 6 Feb 2017 08:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8033) Clients are not able to do
 failback in colocated HA topology with HTTP connectors
In-Reply-To: <JIRA.12675063.1486388602000@Atlassian.JIRA>
References: <JIRA.12675063.1486388602000@Atlassian.JIRA>
	<JIRA.12675063.1486388602000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675063.1486388602000.64130.1486389120253@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8682 to WFLY-8033:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8033  (was: JBEAP-8682)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: JMS)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR10)
                           (was: 7.1.0.DR11)


> Clients are not able to do failback in colocated HA topology with HTTP connectors
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8033
>                 URL: https://issues.jboss.org/browse/WFLY-8033
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>
> *Scenario*:
> * There are two EAPs configured in old way colocated HA topology
> * Start both servers
> * Connect clients to the first server
> * Kill first server
> * Wait until clients do failover
> * Start first server
> * Wait until clients do failback
> *Description of problem:*
> Sometimes happens that after the first server is started again, clients don't do failback. Producers are blocked because they don't have credits for sending. Receivers don't receive any messages.
> In trace logs I can see following messages:
> {code}
> 10:22:52,915 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:792] Trying reconnection attempt 403/-1
> 10:22:52,915 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:792] Trying reconnection attempt 403/-1
> 10:22:53,241 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1070] Trying to connect with connectorFactory = org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory at 6f7ca1c1, connectorConfig=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=9080&host=localhost
> 10:22:53,241 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,242 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:9080
> 10:22:52,743 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:792] Trying reconnection attempt 403/-1
> 10:22:53,242 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1070] Trying to connect with connectorFactory = org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory at 25572f4, connectorConfig=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=9080&host=localhost
> 10:22:53,242 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,242 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:9080
> 10:22:53,242 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: bvTu4ZbJbAqWX5n3TwgNGA==
> 10:22:53,241 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1070] Trying to connect with connectorFactory = org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory at 1c5a232f, connectorConfig=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=9080&host=localhost
> 10:22:53,242 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,242 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:9080
> 10:22:53,241 main INFO  [org.jboss.qa.hornetq.apps.clients.QueueClientsTransAck:178] Producer: Thread[Thread-22,5,main] is still alive.
> 10:22:53,243 main INFO  [org.jboss.qa.hornetq.apps.clients.QueueClientsTransAck:178] Producer: Thread[Thread-23,5,main] is still alive.
> 10:22:53,243 main INFO  [org.jboss.qa.hornetq.apps.clients.QueueClientsTransAck:191] Reciever: Thread[Thread-24,5,] is finished.
> 10:22:53,243 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: vxNO5uMO4KK6etjAlAtorA==
> 10:22:53,243 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: aUC+bE6WaMmU1A6KGcssww==
> 10:22:53,243 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 10:22:53,244 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=8080&host=localhost
> 10:22:53,244 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,244 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:8080
> 10:22:53,244 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 10:22:53,244 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 10:22:53,244 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: plpRSFUDmbA3Xky/5BWx6g==
> 10:22:53,244 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=8080&host=localhost
> 10:22:53,244 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,244 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:8080
> 10:22:53,244 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor-backup&activemqServerName=backup&httpUpgradeEnabled=true&port=8080&host=localhost
> 10:22:53,245 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:542] Started Netty Connector version 4.0.35.Final-redhat-1
> 10:22:53,245 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:602] Remote destination: localhost/127.0.0.1:8080
> 10:22:53,245 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 10:22:53,245 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: f2nehkPE0VDmGlWAcx3Ltg==
> 10:22:53,246 Thread-3 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:672] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET  HTTP/1.1
> Host: localhost
> Upgrade: activemq-remoting
> Connection: Upgrade
> activemqServerName: backup
> httpUpgradeEndpoint: acceptor-backup
> Sec-ActiveMQRemoting-Key: RIaHZ2gy6JEm9nz6XOdyVA==
> 10:22:53,246 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 10:22:53,246 Thread-1 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1104] Backup is not active.
> 10:22:53,246 Thread-1 (ActiveMQ-client-global-threads-1221943800) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1258] Neither backup or live were active, will just give up now
> 10:22:53,245 Thread-2 (ActiveMQ-client-global-threads-1221943800) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1104] Backup is not active.
> 10:22:53,246 Thread-2 (ActiveMQ-client-global-threads-1221943800) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1258] Neither backup or live were active, will just give up now
> 10:22:53,246 Thread-2 (ActiveMQ-client-global-threads-1221943800) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:815] Waiting 2000 milliseconds before next retry. RetryInterval=2000 and multiplier=1.0
> {code}
> You can notice in trace logs that clients try to reconnect only to Artemis backup instances. They don't try any default (live) instance. At the time both Artemis Backup instances are inactive.
> I think if clients are initially connected to Artemis default instance on first server, they should try to reconnect only to this instance or to its backup.
> Note: The same scenario works with remote connectors/acceptors.
> *Customer impact:* Clients may hang after failback in colocated HA topology with HTTP connectors. If it happens, client's application must be restarted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 09:06:01 2017
From: issues at jboss.org (mfoley user (JIRA))
Date: Mon, 6 Feb 2017 09:06:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-24) HOSA --- Hawkular Agent
	for Openshift
In-Reply-To: <JIRA.12674015.1485888026000@Atlassian.JIRA>
References: <JIRA.12674015.1485888026000@Atlassian.JIRA>
	<JIRA.12674015.1485888026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674015.1485888026000.64285.1486389961495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

mfoley user reassigned HAWKULARQE-24:
-------------------------------------

    Assignee: mfoley user  (was: viet nguyen)


> 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: mfoley user
>
> 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  Mon Feb  6 09:09:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 6 Feb 2017 09:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675062.1486388588000@Atlassian.JIRA>
References: <JIRA.12675062.1486388588000@Atlassian.JIRA>
	<JIRA.12675062.1486388588000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675062.1486388588000.64352.1486390140954@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman updated JBJCA-1338:
--------------------------------
    Component/s: JDBC


> 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
>
> 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 Feb  6 09:14:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 09:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7996) Default Elytron subsystem
 configuration doesn't support local authentication in ApplicationRealm
In-Reply-To: <JIRA.12673705.1485788656000@Atlassian.JIRA>
References: <JIRA.12673705.1485788656000@Atlassian.JIRA>
	<JIRA.12673705.1485788656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673705.1485788656000.64406.1486390440725@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359036#comment-13359036 ] 

Jan Kalina commented on WFLY-7996:
----------------------------------

For reference: https://github.com/kwart/wildfly/blob/elytron-basic-ts/testsuite/integration/basic-elytron/src/test/config/enable-elytron.cli

> Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7996
>                 URL: https://issues.jboss.org/browse/WFLY-7996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> 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  Mon Feb  6 09:19:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 6 Feb 2017 09:19:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2205) NPE thrown in jboss-cli
 while defining already defined StringListType attribute
In-Reply-To: <JIRA.12671586.1484662552000@Atlassian.JIRA>
References: <JIRA.12671586.1484662552000@Atlassian.JIRA>
	<JIRA.12671586.1484662552000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671586.1484662552000.64511.1486390741137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-2205:
-----------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2097, https://github.com/wildfly/wildfly-core/pull/2151  (was: https://github.com/wildfly/wildfly-core/pull/2097)


> NPE thrown in jboss-cli while defining already defined StringListType attribute
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-2205
>                 URL: https://issues.jboss.org/browse/WFCORE-2205
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jan Tymel
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha20
>
>
> NullPointerException is thrown when user tries to define already (i.e. previously in current command) defined StringListType attribute. This attempt results in following stack trace and termination of jboss-cli.
> {code}
> /subsystem=elytron/provider-loader=providerLoader:add(providers=[{class-names=[com.example.Class]},class-names=[{com.example.AnotherClass}Exception in thread "Aesh Process Loop 749282235" java.lang.NullPointerException
> 	at org.jboss.as.cli.impl.DeploymentItemCompleter.getCandidates(DeploymentItemCompleter.java:80)
> 	at org.jboss.as.cli.impl.DeploymentItemCompleter.complete(DeploymentItemCompleter.java:53)
> 	at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidatesFromMetadata(ValueTypeCompleter.java:433)
> 	at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getSimpleValues(ValueTypeCompleter.java:690)
> 	at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:573)
> 	at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:346)
> 	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:775)
> 	at org.jboss.aesh.console.Console.execute(Console.java:735)
> 	at org.jboss.aesh.console.Console.access$900(Console.java:73)
> 	at org.jboss.aesh.console.Console$6.run(Console.java:644)
> 	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}
> Expected result:
> No NPE thrown, jboss-cli is not terminated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 09:19:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 6 Feb 2017 09:19:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-924) Coverity static analysis:
 Resource leak in LdapSecurityRealm (Elytron)
In-Reply-To: <JIRA.12672985.1485348453000@Atlassian.JIRA>
References: <JIRA.12672985.1485348453000@Atlassian.JIRA>
	<JIRA.12672985.1485348453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672985.1485348453000.64514.1486390741210@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7964 to ELY-924:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-924  (was: WFLY-7964)
          Component/s:     (was: Security)
    Affects Version/s: 1.1.0.Beta21
                           (was: 11.0.0.Alpha1)


> Coverity static analysis: Resource leak in LdapSecurityRealm (Elytron)
> ----------------------------------------------------------------------
>
>                 Key: ELY-924
>                 URL: https://issues.jboss.org/browse/ELY-924
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity static-analysis scan found resource leak in LdapSecurityRealm.getIdentity().
> It has to be in  try-with-resources, because Stream<LdapIdentity> has registered close handler, where NamingEnumeration.close() is called. Looking into one possible implementation http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/jndi/ldap/LdapNamingEnumeration.java#LdapNamingEnumeration It would be safer to call close() explicitelly.
> However chained stream statement is used in try, which cause 2 Stream objects to be created. But only one of them is closed. Stream created by ldapSearch.search(context) (with exlicitely registered close handler) is not closed.
> {code:java|title=LdapSecurityRealm.java}
> try (
> Stream<LdapIdentity> identityStream = ldapSearch.search(context)
>     .map(result -> new LdapIdentity(result.getNameInNamespace()))
>      ) {
>         LdapIdentity identity = identityStream.findFirst().orElse(null);
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553877&defectInstanceId=2139014&mergedDefectId=1397422



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 09:22:00 2017
From: issues at jboss.org (Sunil kondkar (JIRA))
Date: Mon, 6 Feb 2017 09:22:00 -0500 (EST)
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: <JIRA.12673918.1485869967000@Atlassian.JIRA>
References: <JIRA.12673918.1485869967000@Atlassian.JIRA>
	<JIRA.12673918.1485869967000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673918.1485869967000.64583.1486390920556@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sunil kondkar reassigned HAWKULARQE-10:
---------------------------------------

    Assignee: Sunil kondkar  (was: Filip Brychta)


> [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  Mon Feb  6 09:22:00 2017
From: issues at jboss.org (Sunil kondkar (JIRA))
Date: Mon, 6 Feb 2017 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-12) [QE] - JMAN4-174 -
 Distribute the EAP agent in the EAP 6 RPM channel
In-Reply-To: <JIRA.12673922.1485870171000@Atlassian.JIRA>
References: <JIRA.12673922.1485870171000@Atlassian.JIRA>
	<JIRA.12673922.1485870171000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673922.1485870171000.64592.1486390920879@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sunil kondkar reassigned HAWKULARQE-12:
---------------------------------------

    Assignee: Sunil kondkar  (was: Filip Brychta)


> [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  Mon Feb  6 09:48:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 6 Feb 2017 09:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2268) CLI returns "0" if wildfly
 is not started
In-Reply-To: <JIRA.12675088.1486392460000@Atlassian.JIRA>
References: <JIRA.12675088.1486392460000@Atlassian.JIRA>
	<JIRA.12675088.1486392460527@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675088.1486392460000.65068.1486392481095@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2268:
--------------------------------------------

             Summary: CLI returns "0" if wildfly is not started
                 Key: WFCORE-2268
                 URL: https://issues.jboss.org/browse/WFCORE-2268
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 09:48:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 6 Feb 2017 09:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2268) CLI returns "0" if wildfly
 is not started
In-Reply-To: <JIRA.12675088.1486392461000@Atlassian.JIRA>
References: <JIRA.12675088.1486392461000@Atlassian.JIRA>
	<JIRA.12675088.1486392461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675088.1486392461000.65076.1486392481308@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-2268:
-----------------------------------------
    Priority: Blocker  (was: Major)


> CLI returns "0" if wildfly is not started
> -----------------------------------------
>
>                 Key: WFCORE-2268
>                 URL: https://issues.jboss.org/browse/WFCORE-2268
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 10:00:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Feb 2017 10:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7987) Remove operations should warn
 the user if the resource has any dependents
In-Reply-To: <JIRA.12673524.1485621086000@Atlassian.JIRA>
References: <JIRA.12673524.1485621086000@Atlassian.JIRA>
	<JIRA.12673524.1485621086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673524.1485621086000.65305.1486393201754@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359103#comment-13359103 ] 

Brian Stansberry commented on WFLY-7987:
----------------------------------------

[~ggam] I think it's ok to keep this one for this issue. "Capabilities" is just the internal mechanism for how we will detect and react to the issue you describe here. If you prefer to open a different one that's ok, but this one seems good to me.

Thanks for asking about how fine grained to report issues. If it's easier for you to do lots of small ones that's ok. But a good middle ground is to think of these as referential integrity problems, where something in the configuration of subystem X refers to something in the config of subsystem Y (or in the "kernel" where the kernel means stuff that's in the config not in a subsystem, e.g. a socket-binding.)

If you see a problem between X and Y, then all other problems like that between X and Y are likely related and could be fixed by the same general fix, which is to establish proper capability contracts for X and Y and then wire up the system to use them. The hard work in fixing that is thinking through the contracts and doing that right usually means thinking through an entire subsystem, not just one thing detail. So if you find 3 different attributes between X and Y, they can all go in a general issue "Poor referential integrity between X and Y". If X and Y are the same subsystem, then it becomes "Poor referential integrity within X".

This one is "Poor referential integrity within the Undertow subsystem". From your comment earlier it sounds like you found a problem with "Poor referential integrity within the EJB subsystem."

Thanks!

> 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: Stuart Douglas
>
> 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  Mon Feb  6 10:12:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 6 Feb 2017 10:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8025) Alternatives attribute
 "domain" doesn't exist in modcluster subsystem
In-Reply-To: <JIRA.12674830.1486135726000@Atlassian.JIRA>
References: <JIRA.12674830.1486135726000@Atlassian.JIRA>
	<JIRA.12674830.1486135726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674830.1486135726000.65488.1486393921352@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8025:
---------------------------------
    Affects Version/s: 10.1.0.Final


> Alternatives attribute "domain" doesn't exist in modcluster subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8025
>                 URL: https://issues.jboss.org/browse/WFLY-8025
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Claudio Miranda
>            Assignee: Radoslav Husar
>
> modcluster resource contains the following attribute definition for "load-balancing-group"
> {code}
> "load-balancing-group" => {
>     "type" => STRING,
>     "description" => "loadBalancingGroup name.",
>     "expressions-allowed" => true,
>     "required" => false,
>     "nillable" => true,
>     "alternatives" => ["domain"],
>     "min-length" => 1L,
>     "max-length" => 2147483647L,
>     "access-type" => "read-write",
>     "storage" => "configuration",
>     "restart-required" => "all-services"
> },
> {code}
> But the alternatives constraint specifies a "domain" attribute that doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 10:12:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 6 Feb 2017 10:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8025) Alternatives attribute
 "domain" doesn't exist in modcluster subsystem
In-Reply-To: <JIRA.12674830.1486135726000@Atlassian.JIRA>
References: <JIRA.12674830.1486135726000@Atlassian.JIRA>
	<JIRA.12674830.1486135726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674830.1486135726000.65494.1486393921477@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8025:
---------------------------------
    Priority: Minor  (was: Major)


> Alternatives attribute "domain" doesn't exist in modcluster subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8025
>                 URL: https://issues.jboss.org/browse/WFLY-8025
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Claudio Miranda
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> modcluster resource contains the following attribute definition for "load-balancing-group"
> {code}
> "load-balancing-group" => {
>     "type" => STRING,
>     "description" => "loadBalancingGroup name.",
>     "expressions-allowed" => true,
>     "required" => false,
>     "nillable" => true,
>     "alternatives" => ["domain"],
>     "min-length" => 1L,
>     "max-length" => 2147483647L,
>     "access-type" => "read-write",
>     "storage" => "configuration",
>     "restart-required" => "all-services"
> },
> {code}
> But the alternatives constraint specifies a "domain" attribute that doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 10:16:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 6 Feb 2017 10:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8034) Alternatives attribute
 "domain" doesn't exist in modcluster subsystem
In-Reply-To: <JIRA.12675101.1486394111000@Atlassian.JIRA>
References: <JIRA.12675101.1486394111000@Atlassian.JIRA>
	<JIRA.12675101.1486394111606@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675101.1486394111000.65528.1486394160538@Atlassian.JIRA>

Radoslav Husar created WFLY-8034:
------------------------------------

             Summary: Alternatives attribute "domain" doesn't exist in modcluster subsystem
                 Key: WFLY-8034
                 URL: https://issues.jboss.org/browse/WFLY-8034
             Project: WildFly
          Issue Type: Bug
          Components: mod_cluster
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Minor


modcluster resource contains the following attribute definition for "load-balancing-group"
{code}
"load-balancing-group" => {
    "type" => STRING,
    "description" => "loadBalancingGroup name.",
    "expressions-allowed" => true,
    "required" => false,
    "nillable" => true,
    "alternatives" => ["domain"],
    "min-length" => 1L,
    "max-length" => 2147483647L,
    "access-type" => "read-write",
    "storage" => "configuration",
    "restart-required" => "all-services"
},
{code}

But the alternatives constraint specifies a "domain" attribute that doesn't exist.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 10:19:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 10:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-20) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673942.1485873360000@Atlassian.JIRA>
References: <JIRA.12673942.1485873360000@Atlassian.JIRA>
	<JIRA.12673942.1485873360000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673942.1485873360000.65563.1486394340215@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359127#comment-13359127 ] 

Hayk Hovsepyan commented on HAWKULARQE-20:
------------------------------------------

Test run is created containing test case: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-109%20-%20Monitor%20middleware%20services%20running%20in%20OCP%20with%20external%20middleware%20manager%20instance

> 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  Mon Feb  6 10:40:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 6 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-22) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12673946.1485873694000@Atlassian.JIRA>
References: <JIRA.12673946.1485873694000@Atlassian.JIRA>
	<JIRA.12673946.1485873694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673946.1485873694000.65760.1486395600318@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359152#comment-13359152 ] 

Hayk Hovsepyan commented on HAWKULARQE-22:
------------------------------------------

Created test run with test case inside: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=JMAN4-161%20-%20Monitor%20middleware%20services%20running%20in%20OCP%20with%20OCP%20hosted%20middleware%20manager%20instance

> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-22
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-22
>             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  Mon Feb  6 11:13:02 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Feb 2017 11:13:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8035) Invalidation-cache creation
 fails with Caused by: org.infinispan.commons.CacheConfigurationException:
 ISPN000343: Must have a transport set in the global configuration
In-Reply-To: <JIRA.12675113.1486397557000@Atlassian.JIRA>
References: <JIRA.12675113.1486397557000@Atlassian.JIRA>
	<JIRA.12675113.1486397557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675113.1486397557000.66069.1486397582494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-8689 to WFLY-8035:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8035  (was: JBEAP-8689)
             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.DR11)


> Invalidation-cache creation fails with Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8035
>                 URL: https://issues.jboss.org/browse/WFLY-8035
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> When creating cache in newly creating cache container, it fails with \[1\]. 
> This fails with EAP 7.1.0.DR11 even though this works with EAP 7.0. As this is regression in comparison to EAP 7.0 setting priority to critical.
> \[1\]
> {noformat}
> 16:24:10,561 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-configuration.xxx.aaa: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.xxx.aaa: 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: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration in order to define a clustered cache
> 	at org.infinispan.configuration.cache.ClusteringConfigurationBuilder.validate(ClusteringConfigurationBuilder.java:115)
> 	at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:229)
> 	at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:240)
> 	at org.infinispan.configuration.ConfigurationManager.putConfiguration(ConfigurationManager.java:80)
> 	at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:390)
> 	at org.infinispan.manager.DefaultCacheManager.defineConfiguration(DefaultCacheManager.java:353)
> 	at org.jboss.as.clustering.infinispan.DefaultCacheContainer.defineConfiguration(DefaultCacheContainer.java:73)
> 	at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.start(ConfigurationBuilder.java:88)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	... 3 more
> 16:24:10,562 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "infinispan"),
>     ("cache-container" => "xxx"),
>     ("invalidation-cache" => "aaa")
> ]) - failure description: {
>     "WFLYCTL0080: Failed services" => {"org.wildfly.clustering.infinispan.cache-configuration.xxx.aaa" => "org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.xxx.aaa: Failed to start service
>     Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000343: Must have a transport set in the global configuration in order to define a clustered cache"},
>     "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.clustering.infinispan.cache-configuration.xxx.aaa"]
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 11:49:00 2017
From: issues at jboss.org (Karel Suta (JIRA))
Date: Mon, 6 Feb 2017 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1426) Remove CDI extension from
 drools-compiler
In-Reply-To: <JIRA.12675121.1486399713000@Atlassian.JIRA>
References: <JIRA.12675121.1486399713000@Atlassian.JIRA>
	<JIRA.12675121.1486399713387@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675121.1486399713000.66492.1486399740415@Atlassian.JIRA>

Karel Suta created DROOLS-1426:
----------------------------------

             Summary: Remove CDI extension from drools-compiler
                 Key: DROOLS-1426
                 URL: https://issues.jboss.org/browse/DROOLS-1426
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Karel Suta
            Assignee: Mario Fusco
            Priority: Critical
         Attachments: stacktrace.txt

CDI extension should be removed from drools-compiler [1] as it doesn't belong to core artifact. It can cause issues when deploying on various application servers like on WebSphere using Kie server - see attachment.


[1] https://github.com/droolsjbpm/drools/blob/7.0.0.Beta6/drools-compiler/src/main/resources/META-INF/services/javax.enterprise.inject.spi.Extension



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 11:49:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 6 Feb 2017 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2269) Add transformers for IO
	subsystem
In-Reply-To: <JIRA.12675122.1486399715000@Atlassian.JIRA>
References: <JIRA.12675122.1486399715000@Atlassian.JIRA>
	<JIRA.12675122.1486399715546@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675122.1486399715000.66497.1486399740568@Atlassian.JIRA>

Tomaz Cerar created WFCORE-2269:
-----------------------------------

             Summary: Add transformers for IO subsystem
                 Key: WFCORE-2269
                 URL: https://issues.jboss.org/browse/WFCORE-2269
             Project: WildFly Core
          Issue Type: Task
          Components: IO
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


 WORKER_TASK_KEEPALIVE changed default from 60 to 60_000 and it needs transformer now.

This task is to examine if any other cases require transformers as well and add them.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 11:50:00 2017
From: issues at jboss.org (Karel Suta (JIRA))
Date: Mon, 6 Feb 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1426) Remove CDI extension from
 drools-compiler
In-Reply-To: <JIRA.12675121.1486399713000@Atlassian.JIRA>
References: <JIRA.12675121.1486399713000@Atlassian.JIRA>
	<JIRA.12675121.1486399713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675121.1486399713000.66500.1486399800319@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Suta updated DROOLS-1426:
-------------------------------
    Labels: reported-by-qe  (was: )


> Remove CDI extension from drools-compiler
> -----------------------------------------
>
>                 Key: DROOLS-1426
>                 URL: https://issues.jboss.org/browse/DROOLS-1426
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Karel Suta
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: reported-by-qe
>         Attachments: stacktrace.txt
>
>
> CDI extension should be removed from drools-compiler [1] as it doesn't belong to core artifact. It can cause issues when deploying on various application servers like on WebSphere using Kie server - see attachment.
> [1] https://github.com/droolsjbpm/drools/blob/7.0.0.Beta6/drools-compiler/src/main/resources/META-INF/services/javax.enterprise.inject.spi.Extension



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 12:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 12:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-925) Update SecurityDomain to allow
 association with and retrieval from ClassLoader
In-Reply-To: <JIRA.12675126.1486401248000@Atlassian.JIRA>
References: <JIRA.12675126.1486401248000@Atlassian.JIRA>
	<JIRA.12675126.1486401248795@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675126.1486401248000.66658.1486401300161@Atlassian.JIRA>

Darran Lofthouse created ELY-925:
------------------------------------

             Summary: Update SecurityDomain to allow association with and retrieval from ClassLoader
                 Key: ELY-925
                 URL: https://issues.jboss.org/browse/ELY-925
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: API / SPI
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Beta23


Get, Set, and Unset should all be backed by SecurityManager permissions.

We may relax the permission assigned to Get once we have double checked sufficient permission checks on the SecurityDomain and SecurityIdentity.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 13:35:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 13:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.66896.1486406100291@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359251#comment-13359251 ] 

Jan Kalina commented on ELY-902:
--------------------------------

*Low level problem:* following returns false:
{code}securityDomain.getEvidenceVerifySupport(evidenceType).mayBeSupported(){code}

> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 13:35:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 13:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.66901.1486406100484@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-902:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 13:45:00 2017
From: issues at jboss.org (Zoran Regvart (JIRA))
Date: Mon, 6 Feb 2017 13:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693011@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.66910.1486406700302@Atlassian.JIRA>

Zoran Regvart created ELY-926:
---------------------------------

             Summary: 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
    Affects Versions: 1.1.0.Beta23
         Environment: JDK with JDK-8005408
            Reporter: Zoran Regvart
            Assignee: Zoran Regvart
            Priority: Minor


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  Mon Feb  6 13:54:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 6 Feb 2017 13:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.66928.1486407240212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359251#comment-13359251 ] 

Jan Kalina edited comment on ELY-902 at 2/6/17 1:53 PM:
--------------------------------------------------------

*Low level problem:* obtainContext() throws in:
{code}ldapRealm.getEvidenceVerifySupport(PasswordGuessEvidence, null){code}


was (Author: honza889):
*Low level problem:* following returns false:
{code}securityDomain.getEvidenceVerifySupport(evidenceType).mayBeSupported(){code}

> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 14:07:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.66975.1486408020362@Atlassian.JIRA>


     [ 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


> 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  Mon Feb  6 14:07:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.66972.1486408020267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-926:
---------------------------------
    Affects Version/s:     (was: 1.1.0.Beta23)


> 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  Mon Feb  6 14:50:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8036) Undertow - Associate the
 Elytron SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675146.1486410551000@Atlassian.JIRA>
References: <JIRA.12675146.1486410551000@Atlassian.JIRA>
	<JIRA.12675146.1486410551175@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675146.1486410551000.67199.1486410600339@Atlassian.JIRA>

Darran Lofthouse created WFLY-8036:
--------------------------------------

             Summary: Undertow - Associate the Elytron SecurityDomain with the deployment's ClassLoader
                 Key: WFLY-8036
                 URL: https://issues.jboss.org/browse/WFLY-8036
             Project: WildFly
          Issue Type: Task
          Components: Web (Undertow)
            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 Feb  6 14:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8037) EJB - Associate the Elytron
 SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675148.1486410671000@Atlassian.JIRA>
References: <JIRA.12675148.1486410671000@Atlassian.JIRA>
	<JIRA.12675148.1486410671683@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675148.1486410671000.67205.1486410720413@Atlassian.JIRA>

Darran Lofthouse created WFLY-8037:
--------------------------------------

             Summary: EJB - Associate the Elytron SecurityDomain with the deployment's ClassLoader
                 Key: WFLY-8037
                 URL: https://issues.jboss.org/browse/WFLY-8037
             Project: WildFly
          Issue Type: Task
          Components: Web (Undertow)
            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 Feb  6 14:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8037) EJB - Associate the Elytron
 SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675148.1486410672000@Atlassian.JIRA>
References: <JIRA.12675148.1486410672000@Atlassian.JIRA>
	<JIRA.12675148.1486410672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675148.1486410672000.67216.1486410720676@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-8037:
--------------------------------------

    Assignee: Farah Juma  (was: Darran Lofthouse)


> EJB - Associate the Elytron SecurityDomain with the deployment's ClassLoader
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8037
>                 URL: https://issues.jboss.org/browse/WFLY-8037
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Farah Juma
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 14:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8037) EJB - Associate the Elytron
 SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675148.1486410672000@Atlassian.JIRA>
References: <JIRA.12675148.1486410672000@Atlassian.JIRA>
	<JIRA.12675148.1486410672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675148.1486410672000.67209.1486410720495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8037:
-----------------------------------
    Component/s: EJB
                     (was: Web (Undertow))


> EJB - Associate the Elytron SecurityDomain with the deployment's ClassLoader
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8037
>                 URL: https://issues.jboss.org/browse/WFLY-8037
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            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 Feb  6 14:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 14:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8037) EJB - Associate the Elytron
 SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675148.1486410672000@Atlassian.JIRA>
References: <JIRA.12675148.1486410672000@Atlassian.JIRA>
	<JIRA.12675148.1486410672000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675148.1486410672000.67212.1486410720591@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8037:
-----------------------------------
    Priority: Critical  (was: Major)


> EJB - Associate the Elytron SecurityDomain with the deployment's ClassLoader
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8037
>                 URL: https://issues.jboss.org/browse/WFLY-8037
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            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  Mon Feb  6 15:41:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 6 Feb 2017 15:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8036) Undertow - Associate the
 Elytron SecurityDomain with the deployment's ClassLoader
In-Reply-To: <JIRA.12675146.1486410551000@Atlassian.JIRA>
References: <JIRA.12675146.1486410551000@Atlassian.JIRA>
	<JIRA.12675146.1486410551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675146.1486410551000.67650.1486413660454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8036:
-----------------------------------
    Priority: Critical  (was: Major)


> Undertow - Associate the Elytron SecurityDomain with the deployment's ClassLoader
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8036
>                 URL: https://issues.jboss.org/browse/WFLY-8036
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>            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  Mon Feb  6 17:24:00 2017
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 6 Feb 2017 17:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6224) IllegalStateException
 "transaction is not in a valid state" during a 2clusters test
In-Reply-To: <JIRA.12604138.1455626858000@Atlassian.JIRA>
References: <JIRA.12604138.1455626858000@Atlassian.JIRA>
	<JIRA.12604138.1455626858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12604138.1455626858000.68182.1486419840295@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359344#comment-13359344 ] 

Lucas Ponce commented on WFLY-6224:
-----------------------------------

I have also a similar issue in Hawkular:
{code}
2017-02-06 23:16:31,422 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-3) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=662}, status=1} is not in a valid state to be invoking cache operations on.
	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
	at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
	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.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
	at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
	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.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.InterceptorChain.invoke(InterceptorChain.java:336)
	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
	at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
	at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
	at org.hawkular.alerts.engine.impl.PartitionManagerImpl.notifyTrigger(PartitionManagerImpl.java:276)
{code}

I see the bug is still open and target is 1.2.0.Final. 
Is there any workaround available that can be applied on 1.0.0.Final ?

> IllegalStateException "transaction is not in a valid state" during a 2clusters test
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-6224
>                 URL: https://issues.jboss.org/browse/WFLY-6224
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Ladislav Thon
>            Assignee: Paul Ferraro
>             Fix For: 10.2.0.Final
>
>
> During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{IllegalStateException: Transaction is not in a valid state to be invoking cache operations on}}:
> {code}
> 05:12:09,813 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-40) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=352}, status=3} is not in a valid state to be invoking cache operations on.
> 	at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> 	at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> 	at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> 	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.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:85)
> 	at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> 	at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:238)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.release(DistributableCache.java:137)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:168)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> 	at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doOnePhaseCommit(SubordinateAtomicAction.java:247)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doOnePhaseCommit(TransactionImple.java:283)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:85)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.TransactionRequestHandler.processMessage(TransactionRequestHandler.java:139)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 	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}
> The difference from WFLY-4678 is the circumstances.
> In the following text, I'm refering to the nodes by their real names: {{perf17}} is the standalone EJB client, the "forwarder" cluster is {{perf20}} and {{perf21}}, and the "target" cluster is {{perf18}} and {{perf19}}.
> The stack trace above is the first occurence of the exception, it appears on perf19 (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async/21/console-perf19/). At that time, perf18 is just shutting down gracefully, but the perf19 log clearly shows that both Infinispan and JGroups have already figured out that perf18 went away. Still, the absence of graceful shutdown for transactions might be an explanation... except that there's no reason why the cache on perf19 would be in an invalid state if it's perf18 who is going down. So maybe perf19 had to reach out to perf18 for some reason and the exception actually comes from perf18... but the cache is REPL, so perf19 should have all data locally already and it shouldn't really have to reach out to perf18.
> So, not really sure why it happens.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 20:37:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Feb 2017 20:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2270) Capability registry should
 not allow more than one registration point for a
 RuntimeCapabilityRegistration
In-Reply-To: <JIRA.12675177.1486431418000@Atlassian.JIRA>
References: <JIRA.12675177.1486431418000@Atlassian.JIRA>
	<JIRA.12675177.1486431418981@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675177.1486431418000.68381.1486431420065@Atlassian.JIRA>

Brian Stansberry created WFCORE-2270:
----------------------------------------

             Summary: Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
                 Key: WFCORE-2270
                 URL: https://issues.jboss.org/browse/WFCORE-2270
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 20:52:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Feb 2017 20:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8038) Subsystem tests are
 registering the same capability in multiple spots; clean this up
In-Reply-To: <JIRA.12675178.1486432299000@Atlassian.JIRA>
References: <JIRA.12675178.1486432299000@Atlassian.JIRA>
	<JIRA.12675178.1486432299376@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675178.1486432299000.68386.1486432320070@Atlassian.JIRA>

Brian Stansberry created WFLY-8038:
--------------------------------------

             Summary: Subsystem tests are registering the same capability in multiple spots; clean this up
                 Key: WFLY-8038
                 URL: https://issues.jboss.org/browse/WFLY-8038
             Project: WildFly
          Issue Type: Task
          Components: Batch, EJB, JCA, Web (Undertow)
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


A number of subsystem modules in their tests are registering the same capability in more than one place. This is incorrect behavior and WFCORE-2270 will reject it. This task is to clean this up so WFCORE-2270 can progress.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 20:53:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 6 Feb 2017 20:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8039) Subsystem tests are
 registering the same capability in multiple spots; clean this up
In-Reply-To: <JIRA.12675179.1486432342000@Atlassian.JIRA>
References: <JIRA.12675179.1486432342000@Atlassian.JIRA>
	<JIRA.12675179.1486432342356@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675179.1486432342000.68389.1486432380405@Atlassian.JIRA>

Brian Stansberry created WFLY-8039:
--------------------------------------

             Summary: Subsystem tests are registering the same capability in multiple spots; clean this up
                 Key: WFLY-8039
                 URL: https://issues.jboss.org/browse/WFLY-8039
             Project: WildFly
          Issue Type: Task
          Components: Batch, EJB, JCA, Web (Undertow)
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


A number of subsystem modules in their tests are registering the same capability in more than one place. This is incorrect behavior and WFCORE-2270 will reject it. This task is to clean this up so WFCORE-2270 can progress.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb  6 21:11:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 6 Feb 2017 21:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8040) Infinispan subsystem
 registers duplicate capabilities when using ha profiles
In-Reply-To: <JIRA.12675181.1486433416000@Atlassian.JIRA>
References: <JIRA.12675181.1486433416000@Atlassian.JIRA>
	<JIRA.12675181.1486433416910@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675181.1486433416000.68419.1486433460099@Atlassian.JIRA>

Paul Ferraro created WFLY-8040:
----------------------------------

             Summary: Infinispan subsystem registers duplicate capabilities when using ha profiles
                 Key: WFLY-8040
                 URL: https://issues.jboss.org/browse/WFLY-8040
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


The Infinispan subsystem registers capabilities for local implementations of the clustering API.  When the JGroups subsystem is *not* installed, the Inifinispan subsystem is meant to register its local implementations as the default implementation.  However, currently it is always registering them, causing duplicate capability registrations.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 01:08:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 7 Feb 2017 01:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7104) Elytron properties-realm
 enforces REALM_NAME comment
In-Reply-To: <JIRA.12650135.1473851949000@Atlassian.JIRA>
References: <JIRA.12650135.1473851949000@Atlassian.JIRA>
	<JIRA.12650135.1473851949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650135.1473851949000.68582.1486447680547@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reopened WFLY-7104:
-------------------------------


Reopening. The issue is still valid.

> Elytron properties-realm enforces REALM_NAME comment
> ----------------------------------------------------
>
>                 Key: WFLY-7104
>                 URL: https://issues.jboss.org/browse/WFLY-7104
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>             Fix For: 11.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 Feb  7 01:09:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 7 Feb 2017 01:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7104) Elytron properties-realm
 enforces REALM_NAME comment
In-Reply-To: <JIRA.12650135.1473851949000@Atlassian.JIRA>
References: <JIRA.12650135.1473851949000@Atlassian.JIRA>
	<JIRA.12650135.1473851949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650135.1473851949000.68591.1486447740900@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-7104:
------------------------------
    Steps to Reproduce: 
{code}
touch /tmp/users.properties
bin/jboss-cli.sh -c "/subsystem=elytron/properties-realm=test:add(users-properties={path=/tmp/users.properties, plain-text=true})"
{
    "outcome" => "failed",
    "failure-description" => {
        "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain \"#$REALM_NAME=RealmName$\" line"},
        "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"]
    },
    "rolled-back" => true
}
{code}

Server log contains then:
{code}
07:00:27,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.test: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain "#$REALM_NAME=RealmName$" line
	at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:194)
	at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:172)
	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:00:27,998 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("properties-realm" => "test")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain \"#$REALM_NAME=RealmName$\" line"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"]
}
07:00:28,009 INFO  [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service org.wildfly.security.security-realm.test
{code}


  was:
{code}
touch /tmp/users.properties
bin/jboss-cli.sh -c "/subsystem=elytron/properties-realm=test:add(users-properties={path=/tmp/users.properties}, plain-text=true)"
{
    "outcome" => "failed",
    "failure-description" => {
        "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
    Caused by: java.io.IOException: ELY01006: No realm name found in properties file"},
        "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"],
        "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
    },
    "rolled-back" => true
}
{code}

Server log contains then:
{code}
13:09:20,521 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.test: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
        at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:181)
        at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:162)
        at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
        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.io.IOException: ELY01006: No realm name found in properties file
        at org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm.load(LegacyPropertiesSecurityRealm.java:260)
        at org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.build(LegacyPropertiesSecurityRealm.java:335)
        at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:178)
        ... 7 more

13:09:20,522 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("properties-realm" => "test")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
    Caused by: java.io.IOException: ELY01006: No realm name found in properties file"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
13:09:20,528 INFO  [org.jboss.as.controller] (management-handler-thread - 5) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service org.wildfly.security.security-realm.test
{code}




> Elytron properties-realm enforces REALM_NAME comment
> ----------------------------------------------------
>
>                 Key: WFLY-7104
>                 URL: https://issues.jboss.org/browse/WFLY-7104
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>             Fix For: 11.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 Feb  7 05:02:01 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 7 Feb 2017 05:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8041) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675220.1486461667000@Atlassian.JIRA>
References: <JIRA.12675220.1486461667000@Atlassian.JIRA>
	<JIRA.12675220.1486461667957@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675220.1486461667000.69398.1486461721914@Atlassian.JIRA>

Tomas Hofman created WFLY-8041:
----------------------------------

             Summary: CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
                 Key: WFLY-8041
                 URL: https://issues.jboss.org/browse/WFLY-8041
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 10.1.0.Final
            Reporter: Tomas Hofman
            Assignee: Stefano Maestri


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  Tue Feb  7 05:06:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 7 Feb 2017 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675062.1486388588000@Atlassian.JIRA>
References: <JIRA.12675062.1486388588000@Atlassian.JIRA>
	<JIRA.12675062.1486388588000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675062.1486388588000.69438.1486461960653@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359497#comment-13359497 ] 

Tomas Hofman commented on JBJCA-1338:
-------------------------------------

PR with a suggested solution.

> 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
>
> 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  Tue Feb  7 05:06:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 7 Feb 2017 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675062.1486388588000@Atlassian.JIRA>
References: <JIRA.12675062.1486388588000@Atlassian.JIRA>
	<JIRA.12675062.1486388588000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675062.1486388588000.69441.1486461960716@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned JBJCA-1338:
-----------------------------------

    Assignee: Tomas Hofman


> 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  Tue Feb  7 05:07:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 7 Feb 2017 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675062.1486388588000@Atlassian.JIRA>
References: <JIRA.12675062.1486388588000@Atlassian.JIRA>
	<JIRA.12675062.1486388588000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675062.1486388588000.69444.1486462020425@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359497#comment-13359497 ] 

Tomas Hofman edited comment on JBJCA-1338 at 2/7/17 5:06 AM:
-------------------------------------------------------------

PR with a suggested solution: https://github.com/ironjacamar/ironjacamar/pull/602


was (Author: thofman):
PR with a suggested solution.

> 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  Tue Feb  7 05:07:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 7 Feb 2017 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can
 open a transaction,
 preventing application from changing transaction isolation level
 (PostgreSQL)
In-Reply-To: <JIRA.12675064.1486388666000@Atlassian.JIRA>
References: <JIRA.12675064.1486388666000@Atlassian.JIRA>
	<JIRA.12675064.1486388666000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675064.1486388666000.69449.1486462020742@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359499#comment-13359499 ] 

Tomas Hofman commented on WFLY-8032:
------------------------------------

I sent a PR with a suggested solution: https://github.com/ironjacamar/ironjacamar/pull/602

> 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: Stefano Maestri
>
> 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  Tue Feb  7 05:34:00 2017
From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA))
Date: Tue, 7 Feb 2017 05:34: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: <JIRA.12675227.1486463554000@Atlassian.JIRA>
References: <JIRA.12675227.1486463554000@Atlassian.JIRA>
	<JIRA.12675227.1486463554000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675227.1486463554000.69818.1486463640638@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Panagiotis Sotiropoulos moved JBEAP-8697 to WFLY-8042:
------------------------------------------------------

           Project: WildFly  (was: JBoss Enterprise Application Platform)
               Key: WFLY-8042  (was: JBEAP-8697)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: JSF
                        (was: JSF)
    Target Release:   (was: 7.1.0.GA)


> 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  Tue Feb  7 06:52:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Feb 2017 06:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2156) COUNTER does not work with
 ForkChannel on an already connected main channel
In-Reply-To: <JIRA.12675248.1486468319000@Atlassian.JIRA>
References: <JIRA.12675248.1486468319000@Atlassian.JIRA>
	<JIRA.12675248.1486468319422@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675248.1486468319000.70366.1486468320540@Atlassian.JIRA>

Bela Ban created JGRP-2156:
------------------------------

             Summary: COUNTER does not work with ForkChannel on an already connected main channel
                 Key: JGRP-2156
                 URL: https://issues.jboss.org/browse/JGRP-2156
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0, 3.6.13


The following code doesn't work:
{code:java}
JChannel ch=new JChannel().connect("cluster");
ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true,
                                       ProtocolStack.Position.ABOVE, FRAG2.class,
                                       new COUNTER());
CounterService counter_service=new CounterService(fc);
fc.connect("ignore");
Counter counter=counter_service.getOrCreateCounter("cntr", 0);
{code}

Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called.

SOLUTION: add view change processing in down().



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 06:54:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Feb 2017 06:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2156) COUNTER does not work with
 ForkChannel on an already connected main channel
In-Reply-To: <JIRA.12675248.1486468319000@Atlassian.JIRA>
References: <JIRA.12675248.1486468319000@Atlassian.JIRA>
	<JIRA.12675248.1486468319000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675248.1486468319000.70387.1486468440783@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359585#comment-13359585 ] 

Bela Ban commented on JGRP-2156:
--------------------------------

Unit test is ForkChannelTest.testCounterService()

> COUNTER does not work with ForkChannel on an already connected main channel
> ---------------------------------------------------------------------------
>
>                 Key: JGRP-2156
>                 URL: https://issues.jboss.org/browse/JGRP-2156
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0, 3.6.13
>
>
> The following code doesn't work:
> {code:java}
> JChannel ch=new JChannel().connect("cluster");
> ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true,
>                                        ProtocolStack.Position.ABOVE, FRAG2.class,
>                                        new COUNTER());
> CounterService counter_service=new CounterService(fc);
> fc.connect("ignore");
> Counter counter=counter_service.getOrCreateCounter("cntr", 0);
> {code}
> Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called.
> SOLUTION: add view change processing in down().



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 06:58:00 2017
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 7 Feb 2017 06:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1426) Remove CDI extension from
 drools-compiler
In-Reply-To: <JIRA.12675121.1486399713000@Atlassian.JIRA>
References: <JIRA.12675121.1486399713000@Atlassian.JIRA>
	<JIRA.12675121.1486399713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675121.1486399713000.70443.1486468680269@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359594#comment-13359594 ] 

Maciej Swiderski commented on DROOLS-1426:
------------------------------------------

this impacts KIE Server on WebSphere (essentially it can be started) after upgrade of hibernate that requires javassist which the collides with WebSphere one that tries to bootstrap CDI which KIE Server does not use. So idea here is to move the CDI related class and extension file to separate jar so it does not affect applications that don't want to use CDI.

> Remove CDI extension from drools-compiler
> -----------------------------------------
>
>                 Key: DROOLS-1426
>                 URL: https://issues.jboss.org/browse/DROOLS-1426
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Karel Suta
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: reported-by-qe
>         Attachments: stacktrace.txt
>
>
> CDI extension should be removed from drools-compiler [1] as it doesn't belong to core artifact. It can cause issues when deploying on various application servers like on WebSphere using Kie server - see attachment.
> [1] https://github.com/droolsjbpm/drools/blob/7.0.0.Beta6/drools-compiler/src/main/resources/META-INF/services/javax.enterprise.inject.spi.Extension



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:02:00 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Tue, 7 Feb 2017 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6412) Timer fails if transaction
 isolation set to SERIALIZABLE on Oracle 11g
In-Reply-To: <JIRA.12611317.1458572989000@Atlassian.JIRA>
References: <JIRA.12611317.1458572989000@Atlassian.JIRA>
	<JIRA.12611317.1458572989000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611317.1458572989000.70480.1486468920614@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359601#comment-13359601 ] 

Wolf-Dieter Fink commented on WFLY-6412:
----------------------------------------

The same happen for any other database

Here Postgres Stacktrace:

Caused by: org.postgresql.util.PSQLException: ERROR: could not serialize access due to concurrent update
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2455)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2155)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:288)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:430)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:356)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:168)
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:135)
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.postgresql.ds.PGPooledConnection$StatementHandler.invoke(PGPooledConnection.java:423)
at com.sun.proxy.$Proxy10.executeUpdate(Unknown Source)
at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.shouldRun(DatabaseTimerPersistence.java:410)

> Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6412
>                 URL: https://issues.jboss.org/browse/WFLY-6412
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>         Environment: Linux, JDK8, Oracle DB 11g
>            Reporter: G?bor P?ntek
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the 
> UPDATE JBOSS_EJB_TIMER.. 
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb  7 07:02:00 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Tue, 7 Feb 2017 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8043) Timer fails if transaction
 isolation set to SERIALIZABLE on Oracle 11g
In-Reply-To: <JIRA.12675253.1486468920000@Atlassian.JIRA>
References: <JIRA.12675253.1486468920000@Atlassian.JIRA>
	<JIRA.12675253.1486468920417@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675253.1486468920000.70486.1486468920918@Atlassian.JIRA>

Wolf-Dieter Fink created WFLY-8043:
--------------------------------------

             Summary: Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
                 Key: WFLY-8043
                 URL: https://issues.jboss.org/browse/WFLY-8043
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.2.0.Final, 10.0.0.Final
         Environment: Linux, JDK8, Oracle DB 11g
            Reporter: Wolf-Dieter Fink


If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the 
UPDATE JBOSS_EJB_TIMER.. 
the other nodes throw an
ORA-08177: can't serialize access for this transaction
exception.

The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
The serialization exception is also thrown upon server/application startup sometimes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:03:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 7 Feb 2017 07:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2156) COUNTER does not work with
 ForkChannel on an already connected main channel
In-Reply-To: <JIRA.12675248.1486468319000@Atlassian.JIRA>
References: <JIRA.12675248.1486468319000@Atlassian.JIRA>
	<JIRA.12675248.1486468319000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675248.1486468319000.70495.1486468980441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2156.
----------------------------
    Resolution: Done


> COUNTER does not work with ForkChannel on an already connected main channel
> ---------------------------------------------------------------------------
>
>                 Key: JGRP-2156
>                 URL: https://issues.jboss.org/browse/JGRP-2156
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0, 3.6.13
>
>
> The following code doesn't work:
> {code:java}
> JChannel ch=new JChannel().connect("cluster");
> ForkChannel fc=new ForkChannel(ch, "counter-stack", "counter-channel", true,
>                                        ProtocolStack.Position.ABOVE, FRAG2.class,
>                                        new COUNTER());
> CounterService counter_service=new CounterService(fc);
> fc.connect("ignore");
> Counter counter=counter_service.getOrCreateCounter("cntr", 0);
> {code}
> Method {{getOrCreateCounter()}} hangs as its coord is null because it didn't get a view change. The issue is that COUNTER only processes view changes sent from below but not from above. The former happens when the main channel is connected, the latter when ForkChannel.connect() is called.
> SOLUTION: add view change processing in down().



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:03:00 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Tue, 7 Feb 2017 07:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8043) Timer fails if transaction
 isolation set to SERIALIZABLE
In-Reply-To: <JIRA.12675253.1486468920000@Atlassian.JIRA>
References: <JIRA.12675253.1486468920000@Atlassian.JIRA>
	<JIRA.12675253.1486468920000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675253.1486468920000.70492.1486468980378@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink updated WFLY-8043:
-----------------------------------
    Summary: Timer fails if transaction isolation set to SERIALIZABLE  (was: Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g)


> Timer fails if transaction isolation set to SERIALIZABLE
> --------------------------------------------------------
>
>                 Key: WFLY-8043
>                 URL: https://issues.jboss.org/browse/WFLY-8043
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>         Environment: Linux, JDK8, Oracle DB 11g
>            Reporter: Wolf-Dieter Fink
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the 
> UPDATE JBOSS_EJB_TIMER.. 
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:05:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 7 Feb 2017 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-927) Pass additional information to
 Elytron Realm getCredential method
In-Reply-To: <JIRA.12675256.1486469066000@Atlassian.JIRA>
References: <JIRA.12675256.1486469066000@Atlassian.JIRA>
	<JIRA.12675256.1486469066799@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675256.1486469066000.70533.1486469101565@Atlassian.JIRA>

Josef Cacek created ELY-927:
-------------------------------

             Summary: Pass additional information to Elytron Realm getCredential method
                 Key: ELY-927
                 URL: https://issues.jboss.org/browse/ELY-927
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse


There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration.

This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13359588] with HipChat discussion.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:12:02 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 7 Feb 2017 07:12:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8044) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518064@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.70669.1486469522457@Atlassian.JIRA>

Ondrej Lukas created WFLY-8044:
----------------------------------

             Summary: Wrong type of Elytron match-no-user in XSD
                 Key: WFLY-8044
                 URL: https://issues.jboss.org/browse/WFLY-8044
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


{{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:13:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 7 Feb 2017 07:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8044) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.70693.1486469581291@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8044:
-------------------------------
    Labels: user_experience  (was: )


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: WFLY-8044
>                 URL: https://issues.jboss.org/browse/WFLY-8044
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 07:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-927) Pass additional information to
 Elytron Realm getCredential method
In-Reply-To: <JIRA.12675256.1486469067000@Atlassian.JIRA>
References: <JIRA.12675256.1486469067000@Atlassian.JIRA>
	<JIRA.12675256.1486469067000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675256.1486469067000.70716.1486469700597@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359624#comment-13359624 ] 

Darran Lofthouse commented on ELY-927:
--------------------------------------

Also we may still have some cases where we want to pass additional information from the mech to the realm.  We can use a specific credential type for the result but we still can't get the additional information into the RealmIdenty.

As an example session based Digest needs the nonce passing over.  The purpose of this is we can make a remote call to obtain a credential representation valid only for this session, even if the heap was compromised the credential instances on the heap would only be valid for a specific session and could not be used for new sessions.

> Pass additional information to Elytron Realm getCredential method
> -----------------------------------------------------------------
>
>                 Key: ELY-927
>                 URL: https://issues.jboss.org/browse/ELY-927
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>
> There should be a possibility to retrieve additional information (e.g. Digest Realm name) in the realms when calling {{getCredential}} method. Currently such info has to be provided (duplicated) in the realm configuration.
> This issue is created as follow up for JBEAP-6003. See [this comment|https://issues.jboss.org/browse/JBEAP-6003?focusedCommentId=13359588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13359588] with HipChat discussion.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:16:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 07:16:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8044) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.70735.1486469761802@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359627#comment-13359627 ] 

Darran Lofthouse commented on WFLY-8044:
----------------------------------------

I don't think that is user_experience, I think that is a plain and simple bug ;-)

> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: WFLY-8044
>                 URL: https://issues.jboss.org/browse/WFLY-8044
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta23
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:16:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 07:16:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.70756.1486469762808@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-8044 to ELY-928:
--------------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-928  (was: WFLY-8044)
    Component/s: Authentication Client
                     (was: Security)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta23
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:16:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 07:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.70769.1486469763170@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.1.0.Beta23


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta23
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 07:26:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Tue, 7 Feb 2017 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8045) test suite can't start server
 when -Ddebug is used
In-Reply-To: <JIRA.12675271.1486470315000@Atlassian.JIRA>
References: <JIRA.12675271.1486470315000@Atlassian.JIRA>
	<JIRA.12675271.1486470315170@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675271.1486470315000.70878.1486470360360@Atlassian.JIRA>

Martin Simka created WFLY-8045:
----------------------------------

             Summary: 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.<init>(ServerSocket.java:237)
        at java.net.ServerSocket.<init>(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  Tue Feb  7 07:28:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 7 Feb 2017 07:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1427) Get rid of
	kie-eap-integration modules
In-Reply-To: <JIRA.12675274.1486470437000@Atlassian.JIRA>
References: <JIRA.12675274.1486470437000@Atlassian.JIRA>
	<JIRA.12675274.1486470437482@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675274.1486470437000.70907.1486470480462@Atlassian.JIRA>

Petr ?irok? created DROOLS-1427:
-----------------------------------

             Summary: 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  Tue Feb  7 08:10:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 7 Feb 2017 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8046) Upgrade HAL to 2.9.2.Final
In-Reply-To: <JIRA.12675285.1486472950000@Atlassian.JIRA>
References: <JIRA.12675285.1486472950000@Atlassian.JIRA>
	<JIRA.12675285.1486472950930@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675285.1486472950000.71474.1486473000430@Atlassian.JIRA>

Harald Pehl created WFLY-8046:
---------------------------------

             Summary: Upgrade HAL to 2.9.2.Final
                 Key: WFLY-8046
                 URL: https://issues.jboss.org/browse/WFLY-8046
             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  Tue Feb  7 08:10:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Tue, 7 Feb 2017 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8046) Upgrade HAL to 2.9.2.Final
In-Reply-To: <JIRA.12675285.1486472951000@Atlassian.JIRA>
References: <JIRA.12675285.1486472951000@Atlassian.JIRA>
	<JIRA.12675285.1486472951000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675285.1486472951000.71477.1486473000539@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-8046:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/9546)


> Upgrade HAL to 2.9.2.Final
> --------------------------
>
>                 Key: WFLY-8046
>                 URL: https://issues.jboss.org/browse/WFLY-8046
>             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  Tue Feb  7 09:14:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 7 Feb 2017 09:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from
 Tech Preview release to CFME 4.5 release
In-Reply-To: <JIRA.12675308.1486476803000@Atlassian.JIRA>
References: <JIRA.12675308.1486476803000@Atlassian.JIRA>
	<JIRA.12675308.1486476803844@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675308.1486476803000.72209.1486476840131@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-30:
----------------------------------------

             Summary: [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  Tue Feb  7 09:15:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 7 Feb 2017 09:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8047) Infinispan subsystem
 registers duplicate capabilities when using ha profiles
In-Reply-To: <JIRA.12675309.1486476866000@Atlassian.JIRA>
References: <JIRA.12675309.1486476866000@Atlassian.JIRA>
	<JIRA.12675309.1486476866290@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675309.1486476866000.72215.1486476900550@Atlassian.JIRA>

Paul Ferraro created WFLY-8047:
----------------------------------

             Summary: Infinispan subsystem registers duplicate capabilities when using ha profiles
                 Key: WFLY-8047
                 URL: https://issues.jboss.org/browse/WFLY-8047
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


The Infinispan subsystem registers capabilities for local implementations of the clustering API.  When the JGroups subsystem is *not* installed, the Inifinispan subsystem is meant to register its local implementations as the default implementation.  However, currently it is always registering them, causing duplicate capability registrations.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 09:31:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 7 Feb 2017 09:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.72611.1486477860430@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-903:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
> The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 09:34:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 7 Feb 2017 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-914) Elytron LdapSearch is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674750.1486121342000@Atlassian.JIRA>
References: <JIRA.12674750.1486121342000@Atlassian.JIRA>
	<JIRA.12674750.1486121342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674750.1486121342000.72647.1486478040538@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-914:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Elytron LdapSearch is not able to log arrays correctly
> ------------------------------------------------------
>
>                 Key: ELY-914
>                 URL: https://issues.jboss.org/browse/ELY-914
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when log debug level for class {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.LdapSearch}} is enabled, then arguments and returning attributes are not able to be logged correctly because they are arrays.
> See:
> {code}
> Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@45535736]. Returning attributes are [[Ljava.lang.String;@331d3f34]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 09:49:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 7 Feb 2017 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-914) Elytron LdapSearch is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674750.1486121342000@Atlassian.JIRA>
References: <JIRA.12674750.1486121342000@Atlassian.JIRA>
	<JIRA.12674750.1486121342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674750.1486121342000.72961.1486478940554@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359813#comment-13359813 ] 

Jan Kalina edited comment on ELY-914 at 2/7/17 9:48 AM:
--------------------------------------------------------

Resolved as side effect of ELY-909 PR


was (Author: honza889):
Resolved as part of ELY-909 PR

> Elytron LdapSearch is not able to log arrays correctly
> ------------------------------------------------------
>
>                 Key: ELY-914
>                 URL: https://issues.jboss.org/browse/ELY-914
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>
> In case when log debug level for class {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.LdapSearch}} is enabled, then arguments and returning attributes are not able to be logged correctly because they are arrays.
> See:
> {code}
> Executing search [(uid={0})] in context [ou=People,dc=jboss,dc=org] with arguments [[Ljava.lang.String;@45535736]. Returning attributes are [[Ljava.lang.String;@331d3f34]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 09:49:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 7 Feb 2017 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892166@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.72957.1486478940406@Atlassian.JIRA>

David Lloyd created ELY-929:
-------------------------------

             Summary: 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.Beta23


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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 09:51:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 7 Feb 2017 09:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1427) Get rid of
	kie-eap-integration modules
In-Reply-To: <JIRA.12675274.1486470437000@Atlassian.JIRA>
References: <JIRA.12675274.1486470437000@Atlassian.JIRA>
	<JIRA.12675274.1486470437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675274.1486470437000.73020.1486479060913@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359822#comment-13359822 ] 

Edson Tirelli commented on DROOLS-1427:
---------------------------------------

[~psiroky] , I raised this question yesterday on the integration pack PM meeting. Hiram tells me that even after dropping the switchyard components, camel still requires layered EAP deployments, and so requires modules. It is not a final decision, but at this moment, it looks like we will need to continue to support modules.


> 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  Tue Feb  7 10:14:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 7 Feb 2017 10:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8048) Upgrade mod_cluster to
	1.3.6.CR2
In-Reply-To: <JIRA.12675332.1486480416000@Atlassian.JIRA>
References: <JIRA.12675332.1486480416000@Atlassian.JIRA>
	<JIRA.12675332.1486480416495@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675332.1486480416000.73203.1486480440394@Atlassian.JIRA>

Radoslav Husar created WFLY-8048:
------------------------------------

             Summary: Upgrade mod_cluster to 1.3.6.CR2
                 Key: WFLY-8048
                 URL: https://issues.jboss.org/browse/WFLY-8048
             Project: WildFly
          Issue Type: Component Upgrade
          Components: mod_cluster
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 10:21:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 7 Feb 2017 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8040) Infinispan subsystem
 registers duplicate capabilities when using ha profiles
In-Reply-To: <JIRA.12675181.1486433417000@Atlassian.JIRA>
References: <JIRA.12675181.1486433417000@Atlassian.JIRA>
	<JIRA.12675181.1486433417000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675181.1486433417000.73250.1486480860836@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-8040.
------------------------------
    Resolution: Rejected


Apparently, this is actually ok.

> Infinispan subsystem registers duplicate capabilities when using ha profiles
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8040
>                 URL: https://issues.jboss.org/browse/WFLY-8040
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> The Infinispan subsystem registers capabilities for local implementations of the clustering API.  When the JGroups subsystem is *not* installed, the Inifinispan subsystem is meant to register its local implementations as the default implementation.  However, currently it is always registering them, causing duplicate capability registrations.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 10:21:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 7 Feb 2017 10:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8049) Update Artemis SQL statements
In-Reply-To: <JIRA.12675333.1486480839000@Atlassian.JIRA>
References: <JIRA.12675333.1486480839000@Atlassian.JIRA>
	<JIRA.12675333.1486480839720@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675333.1486480839000.73259.1486480861055@Atlassian.JIRA>

Jeff Mesnil created WFLY-8049:
---------------------------------

             Summary: 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.Alpha1


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  Tue Feb  7 10:24:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 7 Feb 2017 10:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8050) Upgrade Artemis to
	1.5.1.jbossorg-002
In-Reply-To: <JIRA.12675334.1486480967000@Atlassian.JIRA>
References: <JIRA.12675334.1486480967000@Atlassian.JIRA>
	<JIRA.12675334.1486480967000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675334.1486480967000.73312.1486481040232@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8711 to WFLY-8050:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8050  (was: JBEAP-8711)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: ActiveMQ)
                     (was: JMS)


> Upgrade Artemis to 1.5.1.jbossorg-002
> -------------------------------------
>
>                 Key: WFLY-8050
>                 URL: https://issues.jboss.org/browse/WFLY-8050
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> (note that it might be possible that we upgrade to Artemis upstream 1.5.3 instead of 1.5.1.jbossorg-002).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 10:25:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 7 Feb 2017 10:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.73322.1486481100557@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359855#comment-13359855 ] 

Jan Kalina commented on ELY-903:
--------------------------------

Probably problem: realm find R1, find it role R2 and its role R3 - add all of them to the set of already added groups. When later found R2, it does not find its roles, as it was already added...

> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
> The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 10:27:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 7 Feb 2017 10:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.73360.1486481220420@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359855#comment-13359855 ] 

Jan Kalina edited comment on ELY-903 at 2/7/17 10:26 AM:
---------------------------------------------------------

Probably problem: realm find R1, find it role R2 and its role R3 - add all of them to the set of already added groups. When later found R2, it does not find its roles, as it was already added...
Max depth is by random of ways to the node, not by shortest way to the node - need to change algorithm of duplicities prevention.


was (Author: honza889):
Probably problem: realm find R1, find it role R2 and its role R3 - add all of them to the set of already added groups. When later found R2, it does not find its roles, as it was already added...

> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
> The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 11:06:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-923) Elytron LDAP caching realm
 should cache attributes and credentials
In-Reply-To: <JIRA.12675054.1486386810000@Atlassian.JIRA>
References: <JIRA.12675054.1486386810000@Atlassian.JIRA>
	<JIRA.12675054.1486386810000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675054.1486386810000.73754.1486483560340@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-923:
------------------------------------

    Assignee: Jan Kalina


> 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
>
> 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 Feb  7 11:06:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 7 Feb 2017 11:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2151) Client is unable to connect
 to remote+http://localhost:9990 intermittently (the connection timed out)
In-Reply-To: <JIRA.12669334.1483538816000@Atlassian.JIRA>
References: <JIRA.12669334.1483538816000@Atlassian.JIRA>
	<JIRA.12669334.1483538816000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669334.1483538816000.73762.1486483560689@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise resolved WFCORE-2151.
------------------------------------------
    Release Notes Text: This was caused by WFCORE-2241
            Resolution: Duplicate Issue


> Client is unable to connect to remote+http://localhost:9990 intermittently (the connection timed out)
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2151
>                 URL: https://issues.jboss.org/browse/WFCORE-2151
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Remoting
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> Making it a CLI issue for now although I suspect a remoting one. I am running reproducer with traces enabled. Hope to get something. Only managed to reproduce once with 2 millions connect./disconnect but without traces enabled.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 11:23:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 11:23:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-919) Coverity: default platform
 encoding used in DefaultSingleSignOnSessionFactory
In-Reply-To: <JIRA.12672831.1485265229000@Atlassian.JIRA>
References: <JIRA.12672831.1485265229000@Atlassian.JIRA>
	<JIRA.12672831.1485265229000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672831.1485265229000.74025.1486484581088@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-919:
---------------------------------
    Fix Version/s: 1.1.0.Beta23


> Coverity: default platform encoding used in DefaultSingleSignOnSessionFactory
> -----------------------------------------------------------------------------
>
>                 Key: ELY-919
>                 URL: https://issues.jboss.org/browse/ELY-919
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 1.1.0.Beta23
>
>
> Coverity static-analysis scan found a String to byte conversion (4xoccurences of {{getBytes()}}) with default platform encoding in the DefaultSingleSignOnSessionFactory method.
> Following code
> {code:java|title=DefaultSingleSignOnSessionFactory.java}
>     @Override
>     public String createLogoutParameter(String sessionId) {
>         try {
>             Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
>             signature.initSign(this.privateKey);
>             Base64.Encoder urlEncoder = Base64.getUrlEncoder();
>             return sessionId + "." + ByteIterator.ofBytes(urlEncoder.encode(ByteIterator.ofBytes(sessionId.getBytes()).sign(signature).drain())).asUtf8String().drainToString();
>         } catch (NoSuchAlgorithmException | InvalidKeyException e) {
>             throw new IllegalStateException(e);
>         }
>     }
>     
>     @Override
>     public String verifyLogoutParameter(String parameter) {
>         String[] parts = parameter.split("\\.");
>         if (parts.length != 2) {
>             throw new IllegalArgumentException(parameter);
>         }
>         try {
>             String localSessionId = ByteIterator.ofBytes(parts[0].getBytes()).asUtf8String().drainToString();
>             Signature signature = Signature.getInstance(DEFAULT_SIGNATURE_ALGORITHM);
>             signature.initVerify(this.certificate);
>             signature.update(localSessionId.getBytes());
>             Base64.Decoder urlDecoder = Base64.getUrlDecoder();
>             if (!ByteIterator.ofBytes(urlDecoder.decode(parts[1].getBytes())).verify(signature)) {
>                 throw log.httpMechSsoInvalidLogoutMessage(localSessionId);
>             }
>             return localSessionId;
>         } catch (NoSuchAlgorithmException | InvalidKeyException e) {
>             throw new IllegalStateException(e);
>         } catch (SignatureException e) {
>             throw new IllegalArgumentException(parameter, e);
>         }
>     }
> {code}                                                                                                                                                                                                             
> The encoding should be specified as argument.
> Setting with high priority, because once default platform encoding UTF-16 will be set, funcionality  do not need to work as intended. Especially when combined with {{asUtf8String()}}, which implies specifying default encoding UTF-8.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8675870&defectInstanceId=2164160&mergedDefectId=1396938
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8675870&defectInstanceId=2164161&mergedDefectId=1396939



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 11:58:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 7 Feb 2017 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2271) CLI should use Endpoint
	executor
In-Reply-To: <JIRA.12675351.1486486620000@Atlassian.JIRA>
References: <JIRA.12675351.1486486620000@Atlassian.JIRA>
	<JIRA.12675351.1486486620373@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675351.1486486620000.74266.1486486680877@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2271:
--------------------------------------------

             Summary: CLI should use Endpoint executor
                 Key: WFCORE-2271
                 URL: https://issues.jboss.org/browse/WFCORE-2271
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


Today the 16 threads (default value) of the ThreadPool attached to the Endpoint are started and never used (except during connection of Controller client).
CLI, instead of instantiating and managing its own Executor, it should re-use the XNIO one and configure its size the way the CLI custom one does.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 12:00:06 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 7 Feb 2017 12:00:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2241) Mem Leak in CLI class
In-Reply-To: <JIRA.12673562.1485769279000@Atlassian.JIRA>
References: <JIRA.12673562.1485769279000@Atlassian.JIRA>
	<JIRA.12673562.1485769279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673562.1485769279000.74309.1486486806218@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359941#comment-13359941 ] 

Jean-Francois Denise commented on WFCORE-2241:
----------------------------------------------

A branch has been created to implement this change: https://github.com/jfdenise/wildfly-core/tree/cli_new_threading
Testing jobs:
https://ci.wildfly.org/viewLog.html?buildId=44476&tab=buildResultsDiv&buildTypeId=WildFlyCore_Experiments
https://ci.wildfly.org/viewLog.html?buildId=44485&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments


> Mem Leak in CLI class
> ---------------------
>
>                 Key: WFCORE-2241
>                 URL: https://issues.jboss.org/browse/WFCORE-2241
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>
> The CLI class offline CommandContext is never terminated. This makes the CommandContext to be referenced from Shutdown Hook and never cleaned.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 12:03:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 7 Feb 2017 12:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2241) Mem Leak in CLI class
In-Reply-To: <JIRA.12673562.1485769279000@Atlassian.JIRA>
References: <JIRA.12673562.1485769279000@Atlassian.JIRA>
	<JIRA.12673562.1485769279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673562.1485769279000.74320.1486486980371@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13359941#comment-13359941 ] 

Jean-Francois Denise edited comment on WFCORE-2241 at 2/7/17 12:02 PM:
-----------------------------------------------------------------------

A branch has been created to implement this change: https://github.com/jfdenise/wildfly-core/tree/cli_new_threading
Testing jobs:
https://ci.wildfly.org/viewLog.html?buildId=44476&tab=buildResultsDiv&buildTypeId=WildFlyCore_Experiments
https://ci.wildfly.org/viewLog.html?buildId=44485&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments
https://ci.wildfly.org/viewLog.html?buildId=44523&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperimentsWindows


was (Author: jdenise):
A branch has been created to implement this change: https://github.com/jfdenise/wildfly-core/tree/cli_new_threading
Testing jobs:
https://ci.wildfly.org/viewLog.html?buildId=44476&tab=buildResultsDiv&buildTypeId=WildFlyCore_Experiments
https://ci.wildfly.org/viewLog.html?buildId=44485&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments


> Mem Leak in CLI class
> ---------------------
>
>                 Key: WFCORE-2241
>                 URL: https://issues.jboss.org/browse/WFCORE-2241
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>
> The CLI class offline CommandContext is never terminated. This makes the CommandContext to be referenced from Shutdown Hook and never cleaned.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 12:19:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 7 Feb 2017 12:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1428) DMN Decision Table not
 resolving variables in context
In-Reply-To: <JIRA.12675358.1486487894000@Atlassian.JIRA>
References: <JIRA.12675358.1486487894000@Atlassian.JIRA>
	<JIRA.12675358.1486487894983@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675358.1486487894000.74455.1486487940178@Atlassian.JIRA>

Edson Tirelli created DROOLS-1428:
-------------------------------------

             Summary: DMN Decision Table not resolving variables in context
                 Key: DROOLS-1428
                 URL: https://issues.jboss.org/browse/DROOLS-1428
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 7.0.0.CR1, 7.0.0.Final
         Attachments: DT_in_context.dmn, image002.png

While doing some test, we might have discovered an issue with inner decision table reusing previous context entry.
 
This is the context:

 !image002.png|thumbnail! 
 
When I run this, I get no result for the decision. I would expect ?red?. I?ve also attached the xml file. Let me know if anything on our serialization is wrong.





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb  7 12:38:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 7 Feb 2017 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2272) Ctrl-C sent on command
 taking long time doesn't cancel the current operation
In-Reply-To: <JIRA.12675363.1486489053000@Atlassian.JIRA>
References: <JIRA.12675363.1486489053000@Atlassian.JIRA>
	<JIRA.12675363.1486489053842@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675363.1486489053000.74536.1486489080130@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2272:
--------------------------------------------

             Summary: Ctrl-C sent on command taking long time doesn't cancel the current operation
                 Key: WFCORE-2272
                 URL: https://issues.jboss.org/browse/WFCORE-2272
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


For example, during a deploy that takes time, a user types Ctrl-C, this does unlock the prompt and the command "seems" to have been interrupted. Actually the command thread has been interrupted but not the remoting task that is in progress. So although the user can think its command has been aborted, it is silently processing in background.

When interruption occurs in a command thread, current remoting task should be canceled. This is what we are doing today when a timeout is set on a command.







--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 13:18:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 7 Feb 2017 13:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying
 dataSource object directly instead of String properties
In-Reply-To: <JIRA.12626053.1463174901000@Atlassian.JIRA>
References: <JIRA.12626053.1463174901000@Atlassian.JIRA>
	<JIRA.12626053.1463174901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626053.1463174901000.74995.1486491480186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated JGRP-2063:
---------------------------------
    Summary: JDBC_PING: allow supplying dataSource object directly instead of String properties  (was: JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook))


> JDBC_PING: allow supplying dataSource object directly instead of String properties
> ----------------------------------------------------------------------------------
>
>                 Key: JGRP-2063
>                 URL: https://issues.jboss.org/browse/JGRP-2063
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.6.9
>            Reporter: Radoslav Husar
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> See WFLY-6599.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 13:18:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 7 Feb 2017 13:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying
 dataSource object directly instead of String-based properties
In-Reply-To: <JIRA.12626053.1463174901000@Atlassian.JIRA>
References: <JIRA.12626053.1463174901000@Atlassian.JIRA>
	<JIRA.12626053.1463174901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626053.1463174901000.74999.1486491480292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated JGRP-2063:
---------------------------------
    Summary: JDBC_PING: allow supplying dataSource object directly instead of String-based properties  (was: JDBC_PING: allow supplying dataSource object directly instead of String properties)


> JDBC_PING: allow supplying dataSource object directly instead of String-based properties
> ----------------------------------------------------------------------------------------
>
>                 Key: JGRP-2063
>                 URL: https://issues.jboss.org/browse/JGRP-2063
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.6.9
>            Reporter: Radoslav Husar
>            Assignee: Bela Ban
>             Fix For: 4.1
>
>
> See WFLY-6599.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 13:25:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 7 Feb 2017 13:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying
 dataSource object directly instead of String-based properties
In-Reply-To: <JIRA.12626053.1463174901000@Atlassian.JIRA>
References: <JIRA.12626053.1463174901000@Atlassian.JIRA>
	<JIRA.12626053.1463174901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626053.1463174901000.75012.1486491900312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned JGRP-2063:
------------------------------------

    Assignee: Radoslav Husar  (was: Bela Ban)


> JDBC_PING: allow supplying dataSource object directly instead of String-based properties
> ----------------------------------------------------------------------------------------
>
>                 Key: JGRP-2063
>                 URL: https://issues.jboss.org/browse/JGRP-2063
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.6.9
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 4.1
>
>
> See WFLY-6599.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 15:20:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 15:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787348@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.75641.1486498800929@Atlassian.JIRA>

Darran Lofthouse created ELY-930:
------------------------------------

             Summary: 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.Beta23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 15:36:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 7 Feb 2017 15:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2270) Capability registry should
 not allow more than one registration point for a
 RuntimeCapabilityRegistration
In-Reply-To: <JIRA.12675177.1486431419000@Atlassian.JIRA>
References: <JIRA.12675177.1486431419000@Atlassian.JIRA>
	<JIRA.12675177.1486431419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675177.1486431419000.75723.1486499760057@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2270:
-------------------------------------
    Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2017-February/005758.html


> Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2270
>                 URL: https://issues.jboss.org/browse/WFCORE-2270
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 15:43:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 7 Feb 2017 15:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2270) Capability registry should
 not allow more than one registration point for a
 RuntimeCapabilityRegistration
In-Reply-To: <JIRA.12675177.1486431419000@Atlassian.JIRA>
References: <JIRA.12675177.1486431419000@Atlassian.JIRA>
	<JIRA.12675177.1486431419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675177.1486431419000.75777.1486500180230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2270:
-------------------------------------
    Description: 
CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place.

There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example:

1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.)
2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config.

I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior.

  was:CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place.



> Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2270
>                 URL: https://issues.jboss.org/browse/WFCORE-2270
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place.
> There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example:
> 1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.)
> 2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config.
> I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 16:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 16:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-135) Release Remoting JMX
	3.0.0.Beta3
In-Reply-To: <JIRA.12675389.1486504246000@Atlassian.JIRA>
References: <JIRA.12675389.1486504246000@Atlassian.JIRA>
	<JIRA.12675389.1486504246275@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675389.1486504246000.76003.1486504260494@Atlassian.JIRA>

Darran Lofthouse created REMJMX-135:
---------------------------------------

             Summary: Release Remoting JMX 3.0.0.Beta3
                 Key: REMJMX-135
                 URL: https://issues.jboss.org/browse/REMJMX-135
             Project: Remoting JMX
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta3






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 16:54:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Feb 2017 16:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-136) RemotingConnector converts
 the AuthenticationContext to an anonymous context
In-Reply-To: <JIRA.12675390.1486504402000@Atlassian.JIRA>
References: <JIRA.12675390.1486504402000@Atlassian.JIRA>
	<JIRA.12675390.1486504402033@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675390.1486504402000.76012.1486504440295@Atlassian.JIRA>

James Perkins created REMJMX-136:
------------------------------------

             Summary: RemotingConnector converts the AuthenticationContext to an anonymous context
                 Key: REMJMX-136
                 URL: https://issues.jboss.org/browse/REMJMX-136
             Project: Remoting JMX
          Issue Type: Bug
            Reporter: James Perkins
            Assignee: James Perkins


If no {{CallbackHandler}} or no JMX credentials are defined the {{org.jboss.remotingjmx.RemotingConnector}} the {{AuthenticationContext}} is converted to an anonymous context.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 16:56:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 7 Feb 2017 16:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-136) RemotingConnector converts
 the AuthenticationContext to an anonymous context
In-Reply-To: <JIRA.12675390.1486504402000@Atlassian.JIRA>
References: <JIRA.12675390.1486504402000@Atlassian.JIRA>
	<JIRA.12675390.1486504402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675390.1486504402000.76013.1486504560058@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated REMJMX-136:
---------------------------------
    Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/27


> RemotingConnector converts the AuthenticationContext to an anonymous context
> ----------------------------------------------------------------------------
>
>                 Key: REMJMX-136
>                 URL: https://issues.jboss.org/browse/REMJMX-136
>             Project: Remoting JMX
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> If no {{CallbackHandler}} or no JMX credentials are defined the {{org.jboss.remotingjmx.RemotingConnector}} the {{AuthenticationContext}} is converted to an anonymous context.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 17:06:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Feb 2017 17:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6412) Timer fails if transaction
 isolation set to SERIALIZABLE on Oracle 11g
In-Reply-To: <JIRA.12611317.1458572989000@Atlassian.JIRA>
References: <JIRA.12611317.1458572989000@Atlassian.JIRA>
	<JIRA.12611317.1458572989000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611317.1458572989000.76028.1486505160367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-6412:
------------------------------------

    Assignee: Stuart Douglas


> Timer fails if transaction isolation set to SERIALIZABLE on Oracle 11g
> ----------------------------------------------------------------------
>
>                 Key: WFLY-6412
>                 URL: https://issues.jboss.org/browse/WFLY-6412
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final, 10.0.0.Final
>         Environment: Linux, JDK8, Oracle DB 11g
>            Reporter: G?bor P?ntek
>            Assignee: Stuart Douglas
>
> If the transaction isolation level is set to SERIALIZABLE if one node aquires the row lock via the 
> UPDATE JBOSS_EJB_TIMER.. 
> the other nodes throw an
> ORA-08177: can't serialize access for this transaction
> exception.
> The timer thats row threw the exception never runs any more, not even in case the other nodes were shut down.
> The serialization exception is also thrown upon server/application startup sometimes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb  7 17:44:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 7 Feb 2017 17:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7846) jboss-web.xml overlay option
	not honored
In-Reply-To: <JIRA.12669064.1483383467000@Atlassian.JIRA>
References: <JIRA.12669064.1483383467000@Atlassian.JIRA>
	<JIRA.12669064.1483383467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669064.1483383467000.76180.1486507440183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFLY-7846:
----------------------------------


> jboss-web.xml overlay option not honored
> ----------------------------------------
>
>                 Key: WFLY-7846
>                 URL: https://issues.jboss.org/browse/WFLY-7846
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 11.0.0.Alpha1
>
>
> The overlay option in jboss-web_10_0.xsd not honored: 
> {code}
>             The overlay element specifies additional static files overlays for this
>             web application. The content of the element should be a folder in the 
>             filesystem containing the static files that will overlay the webapp's
>             static files, similar to what happens with regular JAR overlays.
> {code}
> {code}
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
>            version="10.0">
>   <overlay>/home/web/content</overlay>
> </jboss-web>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 17:59:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 17:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-137) Update components to latest
 used in Wildfly Core
In-Reply-To: <JIRA.12675396.1486508317000@Atlassian.JIRA>
References: <JIRA.12675396.1486508317000@Atlassian.JIRA>
	<JIRA.12675396.1486508317368@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675396.1486508317000.76216.1486508340276@Atlassian.JIRA>

Darran Lofthouse created REMJMX-137:
---------------------------------------

             Summary: Update components to latest used in Wildfly Core
                 Key: REMJMX-137
                 URL: https://issues.jboss.org/browse/REMJMX-137
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta3






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 18:21:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 18:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-135) Release Remoting JMX
	3.0.0.Beta3
In-Reply-To: <JIRA.12675389.1486504246000@Atlassian.JIRA>
References: <JIRA.12675389.1486504246000@Atlassian.JIRA>
	<JIRA.12675389.1486504246000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675389.1486504246000.76308.1486509660263@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-135.
-------------------------------------
    Resolution: Done


> Release Remoting JMX 3.0.0.Beta3
> --------------------------------
>
>                 Key: REMJMX-135
>                 URL: https://issues.jboss.org/browse/REMJMX-135
>             Project: Remoting JMX
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 18:21:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 18:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-137) Update components to latest
 used in Wildfly Core
In-Reply-To: <JIRA.12675396.1486508317000@Atlassian.JIRA>
References: <JIRA.12675396.1486508317000@Atlassian.JIRA>
	<JIRA.12675396.1486508317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675396.1486508317000.76311.1486509660336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/REMJMX-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-137.
-------------------------------------
    Resolution: Done


> Update components to latest used in Wildfly Core
> ------------------------------------------------
>
>                 Key: REMJMX-137
>                 URL: https://issues.jboss.org/browse/REMJMX-137
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 18:25:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 18:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2273) Upgrade Remoting JMX to
	3.0.0.Beta3
In-Reply-To: <JIRA.12675401.1486509871000@Atlassian.JIRA>
References: <JIRA.12675401.1486509871000@Atlassian.JIRA>
	<JIRA.12675401.1486509871494@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675401.1486509871000.76314.1486509900162@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2273:
----------------------------------------

             Summary: Upgrade Remoting JMX to 3.0.0.Beta3
                 Key: WFCORE-2273
                 URL: https://issues.jboss.org/browse/WFCORE-2273
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: JMX
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:02:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-931) Release WildFly Elytron
	1.1.0.Beta23
In-Reply-To: <JIRA.12675404.1486512063000@Atlassian.JIRA>
References: <JIRA.12675404.1486512063000@Atlassian.JIRA>
	<JIRA.12675404.1486512063281@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675404.1486512063000.76348.1486512120847@Atlassian.JIRA>

Darran Lofthouse created ELY-931:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta23
                 Key: ELY-931
                 URL: https://issues.jboss.org/browse/ELY-931
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta23






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:27:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2274) Upgrade to WildFly Elytron
	1.1.0.Beta23
In-Reply-To: <JIRA.12675405.1486513595000@Atlassian.JIRA>
References: <JIRA.12675405.1486513595000@Atlassian.JIRA>
	<JIRA.12675405.1486513595727@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675405.1486513595000.76356.1486513620386@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2274:
----------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta23
                 Key: WFCORE-2274
                 URL: https://issues.jboss.org/browse/WFCORE-2274
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:28:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2275) Upgrade to Elytron Web
	1.0.0.Beta9
In-Reply-To: <JIRA.12675406.1486513661000@Atlassian.JIRA>
References: <JIRA.12675406.1486513661000@Atlassian.JIRA>
	<JIRA.12675406.1486513661957@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675406.1486513661000.76369.1486513680175@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2275:
----------------------------------------

             Summary: Upgrade to Elytron Web 1.0.0.Beta9
                 Key: WFCORE-2275
                 URL: https://issues.jboss.org/browse/WFCORE-2275
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:40:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7977) Synchronize XSD and DMR
 description of obtain-kerberos-ticket attribute
In-Reply-To: <JIRA.12673104.1485417671000@Atlassian.JIRA>
References: <JIRA.12673104.1485417671000@Atlassian.JIRA>
	<JIRA.12673104.1485417671000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673104.1485417671000.76388.1486514400933@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7977:
-----------------------------------
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Synchronize XSD and DMR description of obtain-kerberos-ticket attribute
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7977
>                 URL: https://issues.jboss.org/browse/WFLY-7977
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 11.0.0.Alpha1
>
>
> Add this sentence "This is required to be true where credentials are delegated to the server." to description of obtain-kerberos-ticket attribute.
> {code:Management Model}
>                         "obtain-kerberos-ticket" => {
>                             "type" => BOOLEAN,
>                             "description" => "Should the KerberosTicket also be obtained and associated with the credential.",
>                             "expressions-allowed" => true,
>                             "required" => false,
>                             "nillable" => true,
>                             "default" => false,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {code}
> As already is in XSD 
> {code:xml|title=wildfly-elytron.xsd}
>                 <xs:attribute name="obtain-kerberos-ticket" type="xs:boolean" default="false">
>                     <xs:annotation>
>                         <xs:documentation>
>                             Should the KerberosTicket also be obtained and associated with the credential.
>                             This is required to be true where credentials are delegated to the server.
>                         </xs:documentation>
>                     </xs:annotation>
>                 </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:40:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7977) Synchronize XSD and DMR
 description of obtain-kerberos-ticket attribute
In-Reply-To: <JIRA.12673104.1485417671000@Atlassian.JIRA>
References: <JIRA.12673104.1485417671000@Atlassian.JIRA>
	<JIRA.12673104.1485417671000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673104.1485417671000.76402.1486514401311@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7977:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Synchronize XSD and DMR description of obtain-kerberos-ticket attribute
> -----------------------------------------------------------------------
>
>                 Key: WFLY-7977
>                 URL: https://issues.jboss.org/browse/WFLY-7977
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 11.0.0.Alpha1
>
>
> Add this sentence "This is required to be true where credentials are delegated to the server." to description of obtain-kerberos-ticket attribute.
> {code:Management Model}
>                         "obtain-kerberos-ticket" => {
>                             "type" => BOOLEAN,
>                             "description" => "Should the KerberosTicket also be obtained and associated with the credential.",
>                             "expressions-allowed" => true,
>                             "required" => false,
>                             "nillable" => true,
>                             "default" => false,
>                             "access-type" => "read-write",
>                             "storage" => "configuration",
>                             "restart-required" => "resource-services"
>                         },
> {code}
> As already is in XSD 
> {code:xml|title=wildfly-elytron.xsd}
>                 <xs:attribute name="obtain-kerberos-ticket" type="xs:boolean" default="false">
>                     <xs:annotation>
>                         <xs:documentation>
>                             Should the KerberosTicket also be obtained and associated with the credential.
>                             This is required to be true where credentials are delegated to the server.
>                         </xs:documentation>
>                     </xs:annotation>
>                 </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7653) Validate session-timeout and
 maximum-session-cache-size to be non-negative
In-Reply-To: <JIRA.12663211.1479888953000@Atlassian.JIRA>
References: <JIRA.12663211.1479888953000@Atlassian.JIRA>
	<JIRA.12663211.1479888953000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663211.1479888953000.76438.1486515060322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7653:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Validate session-timeout and maximum-session-cache-size to be non-negative
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7653
>                 URL: https://issues.jboss.org/browse/WFLY-7653
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 11.0.0.Alpha1
>
>
> Negative values are invalid in this case because they do not make sense for these attributes. Also java throws IllegalArgumentException, when they get negative values on that place. [1]
> Please add validation to limit these values to zero and positive values in:
> * model 
> * XSD
> That applies for both:
> * client-ssl-context 
> * server-ssl-context
> [1] http://www.ibm.com/support/knowledgecenter/SSVHEW_6.2.0/com.ibm.rcp.dee.javadoc/doc/javax/net/ssl/SSLSessionContext.html



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7996) Default Elytron subsystem
 configuration doesn't support local authentication in ApplicationRealm
In-Reply-To: <JIRA.12673705.1485788656000@Atlassian.JIRA>
References: <JIRA.12673705.1485788656000@Atlassian.JIRA>
	<JIRA.12673705.1485788656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673705.1485788656000.76446.1486515120324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7996:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7996
>                 URL: https://issues.jboss.org/browse/WFLY-7996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> 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  Tue Feb  7 19:54:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2276) Backport latest Elytron
 Integration changes
In-Reply-To: <JIRA.12675408.1486515214000@Atlassian.JIRA>
References: <JIRA.12675408.1486515214000@Atlassian.JIRA>
	<JIRA.12675408.1486515214139@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675408.1486515214000.76449.1486515240490@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2276:
----------------------------------------

             Summary: Backport latest Elytron Integration changes
                 Key: WFCORE-2276
                 URL: https://issues.jboss.org/browse/WFCORE-2276
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:54:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2277) Backport latest Elytron
 Integration changes
In-Reply-To: <JIRA.12675409.1486515225000@Atlassian.JIRA>
References: <JIRA.12675409.1486515225000@Atlassian.JIRA>
	<JIRA.12675409.1486515225220@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675409.1486515225000.76462.1486515240845@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2277:
----------------------------------------

             Summary: Backport latest Elytron Integration changes
                 Key: WFCORE-2277
                 URL: https://issues.jboss.org/browse/WFCORE-2277
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 19:55:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 19:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8051) Backport latest Elytron
 Integration changes
In-Reply-To: <JIRA.12675409.1486515225000@Atlassian.JIRA>
References: <JIRA.12675409.1486515225000@Atlassian.JIRA>
	<JIRA.12675409.1486515225000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675409.1486515225000.76477.1486515300581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFCORE-2277 to WFLY-8051:
------------------------------------------------

          Project: WildFly  (was: WildFly Core)
              Key: WFLY-8051  (was: WFCORE-2277)
      Component/s: Security
                       (was: Security)
    Fix Version/s: 11.0.0.Alpha1
                       (was: 3.0.0.Alpha24)


> Backport latest Elytron Integration changes
> -------------------------------------------
>
>                 Key: WFLY-8051
>                 URL: https://issues.jboss.org/browse/WFLY-8051
>             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  Tue Feb  7 20:24:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8052) Upgrade to Elytron Subsystem
	1.0.0.Beta5
In-Reply-To: <JIRA.12675411.1486517022000@Atlassian.JIRA>
References: <JIRA.12675411.1486517022000@Atlassian.JIRA>
	<JIRA.12675411.1486517022433@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675411.1486517022000.76510.1486517040406@Atlassian.JIRA>

Darran Lofthouse created WFLY-8052:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Beta5
                 Key: WFLY-8052
                 URL: https://issues.jboss.org/browse/WFLY-8052
             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  Tue Feb  7 20:40:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-925) Update SecurityDomain to allow
 association with and retrieval from ClassLoader
In-Reply-To: <JIRA.12675126.1486401249000@Atlassian.JIRA>
References: <JIRA.12675126.1486401249000@Atlassian.JIRA>
	<JIRA.12675126.1486401249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675126.1486401249000.76563.1486518000465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-925.
----------------------------------
    Resolution: Done


> Update SecurityDomain to allow association with and retrieval from ClassLoader
> ------------------------------------------------------------------------------
>
>                 Key: ELY-925
>                 URL: https://issues.jboss.org/browse/ELY-925
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta23
>
>
> Get, Set, and Unset should all be backed by SecurityManager permissions.
> We may relax the permission assigned to Get once we have double checked sufficient permission checks on the SecurityDomain and SecurityIdentity.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.76576.1486518063196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.1.0.Beta24
                       (was: 1.1.0.Beta23)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta24
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:40:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-931) Release WildFly Elytron
	1.1.0.Beta23
In-Reply-To: <JIRA.12675404.1486512063000@Atlassian.JIRA>
References: <JIRA.12675404.1486512063000@Atlassian.JIRA>
	<JIRA.12675404.1486512063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675404.1486512063000.76567.1486518001201@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-931.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta23
> ------------------------------------
>
>                 Key: ELY-931
>                 URL: https://issues.jboss.org/browse/ELY-931
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta23
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.76572.1486518063056@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.76569.1486518062983@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-921) Elytron FORM authentication
 failing if TRACE is enabled.
In-Reply-To: <JIRA.12673133.1485426006000@Atlassian.JIRA>
References: <JIRA.12673133.1485426006000@Atlassian.JIRA>
	<JIRA.12673133.1485426006000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673133.1485426006000.76583.1486518063488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-921:
---------------------------------
    Fix Version/s: 1.1.0.Beta24
                       (was: 1.1.0.Beta23)


> Elytron FORM authentication failing if TRACE is enabled.
> --------------------------------------------------------
>
>                 Key: ELY-921
>                 URL: https://issues.jboss.org/browse/ELY-921
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta22
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta24
>
>         Attachments: secured-webapp.war.zip
>
>
> NPE occures during FORM authentication when TRACE logging is enabled.  
> {code}
> 11:02:55,488 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/: java.lang.NullPointerException
> 	at org.wildfly.elytron.web.undertow.server.ElytronHttpExchange$4.getID(ElytronHttpExchange.java:401)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptReAuthentication(FormAuthenticationMechanism.java:228)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:99)
> 	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)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	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.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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	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:210)
> 	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}
> {code:java|title=FormAuthenticationMechanism.java}
>         if (log.isTraceEnabled()) {
>             if (getSessionScope(request, false) != null) {
>                 log.tracef("Trying to re-authenticate session %s using FormAuthenticationMechanism. Request URI: [%s], Context path: [%s]",
>                         getSessionScope(request, false).getID(), request.getRequestURI(), this.contextPath);
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.76586.1486518063556@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.76579.1486518063336@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.76589.1486518063769@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.76592.1486518064002@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.76596.1486518064129@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.76599.1486518064270@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.76602.1486518064337@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.76605.1486518064856@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.76610.1486518065519@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.76623.1486518065903@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-835) SecurityIdentity Automatic
	Outflow
In-Reply-To: <JIRA.12667816.1481802782000@Atlassian.JIRA>
References: <JIRA.12667816.1481802782000@Atlassian.JIRA>
	<JIRA.12667816.1481802782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667816.1481802782000.76616.1486518065705@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-835:
---------------------------------
    Fix Version/s: 1.1.0.Beta24
                       (was: 1.1.0.Beta23)


> SecurityIdentity Automatic Outflow
> ----------------------------------
>
>                 Key: ELY-835
>                 URL: https://issues.jboss.org/browse/ELY-835
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta24
>
>
> We previously discussed that when runAs is called on a SecurityIdentity this should pro-actively outflow to predefined security domains (which it has in trusted-security-domains?) so it does not need to be manually inflowed at a later point.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.76634.1486518066671@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.76631.1486518066595@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.Beta24
>
>
> 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  Tue Feb  7 20:41:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.76627.1486518066481@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.Beta24
>
>
> 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  Tue Feb  7 20:41:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41: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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.76637.1486518066808@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.76620.1486518065847@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41: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: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.76640.1486518066971@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:07 -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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.76647.1486518067173@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.76644.1486518067067@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.76651.1486518067482@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler
 interactions to a common base class for HTTP mechanisms, .
In-Reply-To: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.76654.1486518067565@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.76657.1486518068252@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.76661.1486518068412@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.76664.1486518068476@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.76667.1486518068563@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.76671.1486518068697@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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
>             Fix For: 1.1.0.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.76683.1486518068962@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be
 considered to be static nested in Elytron
In-Reply-To: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.76678.1486518068867@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.76686.1486518069043@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.76689.1486518069152@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.76674.1486518068782@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.76692.1486518069220@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.76695.1486518069378@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.76699.1486518069545@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.76702.1486518069632@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the
 'org.wildfly.security.mechanism' package and sub packages.
In-Reply-To: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.76705.1486518069734@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the
 'org.wildfly.security.credential' package and sub packages.
In-Reply-To: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.76708.1486518069825@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:09 -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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.76711.1486518069886@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.76714.1486518070022@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.76719.1486518070157@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.76722.1486518070296@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.76732.1486518070658@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.76729.1486518070515@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> 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  Tue Feb  7 20:41:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 7 Feb 2017 20:41:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.76726.1486518070454@Atlassian.JIRA>


     [ 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.Beta24
                       (was: 1.1.0.Beta23)


> 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.Beta24
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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  Wed Feb  8 00:32:00 2017
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 8 Feb 2017 00:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8053) Warn user when configuration
 change might make server inoperable
In-Reply-To: <JIRA.12675415.1486531913000@Atlassian.JIRA>
References: <JIRA.12675415.1486531913000@Atlassian.JIRA>
	<JIRA.12675415.1486531913341@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675415.1486531913000.76861.1486531920217@Atlassian.JIRA>

Bartosz Baranowski created WFLY-8053:
----------------------------------------

             Summary: Warn user when configuration change might make server inoperable
                 Key: WFLY-8053
                 URL: https://issues.jboss.org/browse/WFLY-8053
             Project: WildFly
          Issue Type: Enhancement
            Reporter: Bartosz Baranowski
            Assignee: Jason Greene






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 02:09:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Wed, 8 Feb 2017 02:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-932) Wrong log exception in
	jdbc-realm
In-Reply-To: <JIRA.12675421.1486537692000@Atlassian.JIRA>
References: <JIRA.12675421.1486537692000@Atlassian.JIRA>
	<JIRA.12675421.1486537692043@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675421.1486537692000.76949.1486537740229@Atlassian.JIRA>

Ondrej Kotek created ELY-932:
--------------------------------

             Summary: Wrong log exception in jdbc-realm
                 Key: ELY-932
                 URL: https://issues.jboss.org/browse/ELY-932
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
    Affects Versions: 1.1.0.Beta21
            Reporter: Ondrej Kotek
            Assignee: Pedro Igor
            Priority: Minor


There is {{ldap-realm}} log exception in {{jdbc-realm}}, see https://github.com/wildfly-security/wildfly-elytron/blob/ce3475fbc74569369513fa294e895e44b6da6dcd/src/main/java/org/wildfly/security/auth/realm/jdbc/JdbcSecurityRealm.java#L229

A new log message will be necessary.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 03:39:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 8 Feb 2017 03:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8054) Remove messaging's required
 dependency to SecurityDomainService
In-Reply-To: <JIRA.12675435.1486543064000@Atlassian.JIRA>
References: <JIRA.12675435.1486543064000@Atlassian.JIRA>
	<JIRA.12675435.1486543064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675435.1486543064000.77425.1486543140364@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8721 to WFLY-8054:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8054  (was: JBEAP-8721)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: JMS)


> Remove messaging's required dependency to SecurityDomainService
> ---------------------------------------------------------------
>
>                 Key: WFLY-8054
>                 URL: https://issues.jboss.org/browse/WFLY-8054
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> The messaging-activemq subsystem can use either a legacy security-domain or the new elytron-domain.
> However, when only elytron-domain is defined (and any legacy security domain is removed), the subsystem fails to boot with the error:
> {code}
> 17:52:34,634 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>    ("subsystem" => "messaging-activemq"),
>    ("server" => "default")
> ]) - failure description: {
>    "WFLYCTL0412: Required services that are not installed:" => ["jboss.security.security-domain.other"],
>    "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.messaging-activemq.default is missing [jboss.security.security-domain.other]"]
> }
> {code}
> The dependency to jboss.security.security-domain.other must be optional and set only when elytron-domain is not defined.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 04:48:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 8 Feb 2017 04:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-749) String.toUpperCase() is used
 without Locale in AttributeMapping class (Elytron)
In-Reply-To: <JIRA.12661256.1479125787000@Atlassian.JIRA>
References: <JIRA.12661256.1479125787000@Atlassian.JIRA>
	<JIRA.12661256.1479125787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661256.1479125787000.77995.1486547280829@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360238#comment-13360238 ] 

Martin Choma commented on ELY-749:
----------------------------------

Just note, elytron and elytron-subsytem use:
- Locale.ROOT
- Locale.ENGLISH
- Locale.US 

Is it worth unifying it?
 [~dmlloyd] ^

> String.toUpperCase() is used without Locale in AttributeMapping class (Elytron)
> -------------------------------------------------------------------------------
>
>                 Key: ELY-749
>                 URL: https://issues.jboss.org/browse/ELY-749
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 1.1.0.Beta17
>
>
> The String.toUpperCase() call is used in constructor of {{AttributeMapping}} class without providing {{Locale.ENGLISH}} or {{Locale.US}} as parameter.
> This can lead to problems on systems with non-English default locale (e.g. {{-Duser.language=tr}}).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 05:13:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Feb 2017 05:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8055) Upgrade h2 to 1.4.193 from
	1.3.176
In-Reply-To: <JIRA.12675452.1486548717000@Atlassian.JIRA>
References: <JIRA.12675452.1486548717000@Atlassian.JIRA>
	<JIRA.12675452.1486548717000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675452.1486548717000.78192.1486548780233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-8724 to WFLY-8055:
------------------------------------------

     Project: WildFly  (was: JBoss Enterprise Application Platform)
         Key: WFLY-8055  (was: JBEAP-8724)
    Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)


> Upgrade h2 to 1.4.193 from 1.3.176
> ----------------------------------
>
>                 Key: WFLY-8055
>                 URL: https://issues.jboss.org/browse/WFLY-8055
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> 1.3.176 requires JDK 6 to do the prod rebuild. It is not recommended for production use anyway.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 06:20:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 06:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying
 dataSource object directly instead of String-based properties
In-Reply-To: <JIRA.12626053.1463174901000@Atlassian.JIRA>
References: <JIRA.12626053.1463174901000@Atlassian.JIRA>
	<JIRA.12626053.1463174901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626053.1463174901000.78617.1486552800161@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated JGRP-2063:
---------------------------------
    Fix Version/s: 4.0
                       (was: 4.1)


> JDBC_PING: allow supplying dataSource object directly instead of String-based properties
> ----------------------------------------------------------------------------------------
>
>                 Key: JGRP-2063
>                 URL: https://issues.jboss.org/browse/JGRP-2063
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.6.9
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 4.0
>
>
> See WFLY-6599.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 07:02:02 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 8 Feb 2017 07:02:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8056) Implement ServerSetupTask to
 simplify configuring Elytron security domains
In-Reply-To: <JIRA.12675486.1486555306000@Atlassian.JIRA>
References: <JIRA.12675486.1486555306000@Atlassian.JIRA>
	<JIRA.12675486.1486555306973@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675486.1486555306000.79014.1486555322611@Atlassian.JIRA>

Josef Cacek created WFLY-8056:
---------------------------------

             Summary: Implement ServerSetupTask to simplify configuring Elytron security domains
                 Key: WFLY-8056
                 URL: https://issues.jboss.org/browse/WFLY-8056
             Project: WildFly
          Issue Type: Task
          Components: Test Suite, Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse


Implement logic similar to 
{{org.jboss.as.test.integration.security.common.AbstractSecurityDomainsServerSetupTask}} which could be used accross AS TS to create Elytron security domains.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 07:02:02 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 8 Feb 2017 07:02:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8056) Implement ServerSetupTask to
 simplify configuring Elytron security domains
In-Reply-To: <JIRA.12675486.1486555307000@Atlassian.JIRA>
References: <JIRA.12675486.1486555307000@Atlassian.JIRA>
	<JIRA.12675486.1486555307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675486.1486555307000.79025.1486555322937@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-8056:
---------------------------------

    Assignee: Josef Cacek  (was: Darran Lofthouse)


> Implement ServerSetupTask to simplify configuring Elytron security domains
> --------------------------------------------------------------------------
>
>                 Key: WFLY-8056
>                 URL: https://issues.jboss.org/browse/WFLY-8056
>             Project: WildFly
>          Issue Type: Task
>          Components: Security, Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Implement logic similar to 
> {{org.jboss.as.test.integration.security.common.AbstractSecurityDomainsServerSetupTask}} which could be used accross AS TS to create Elytron security domains.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 07:40:03 2017
From: issues at jboss.org (=?UTF-8?Q?Daniel_=C4=8Cih=C3=A1k_=28JIRA=29?=)
Date: Wed, 8 Feb 2017 07:40:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6672) EJB's async methods'
 Future#get should treat zero timeout as "don't wait"
In-Reply-To: <JIRA.12629585.1465048287000@Atlassian.JIRA>
References: <JIRA.12629585.1465048287000@Atlassian.JIRA>
	<JIRA.12629585.1465048287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629585.1465048287000.79504.1486557603755@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360371#comment-13360371 ] 

Daniel ?ih?k commented on WFLY-6672:
------------------------------------

Pull request with test https://github.com/wildfly/wildfly/pull/9617.

> EJB's async methods' Future#get should treat zero timeout as "don't wait"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6672
>                 URL: https://issues.jboss.org/browse/WFLY-6672
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Stuart Douglas
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> Say there is an asynchronous EJB method:
> {code}
> @Asynchronous
> public Future<Boolean> method() {
>    ...
> }
> {code}
> Calling Future#get with a zero timeout:
> {code}
> if (bean.method().get(0, TimeUnit.MILLISECONDS))
> {code}
> results in a block until the task is finished.
> Instead I expected zero waiting, because {{java.util.concurrent.Future.get(long, TimeUnit)}} doesn't specify any special treatment for a zero timeout value.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 08:45:01 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Feb 2017 08:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-933) There isn't possibility disable
 create CS file from scratch
In-Reply-To: <JIRA.12675532.1486561500000@Atlassian.JIRA>
References: <JIRA.12675532.1486561500000@Atlassian.JIRA>
	<JIRA.12675532.1486561500202@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675532.1486561500000.80145.1486561501668@Atlassian.JIRA>

Peter Skopek created ELY-933:
--------------------------------

             Summary: There isn't possibility disable create CS file from scratch
                 Key: ELY-933
                 URL: https://issues.jboss.org/browse/ELY-933
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credential Store
    Affects Versions: 1.1.0.Beta20
            Reporter: Peter Skopek
            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  Wed Feb  8 09:06:00 2017
From: issues at jboss.org (=?UTF-8?Q?Daniel_=C4=8Cih=C3=A1k_=28JIRA=29?=)
Date: Wed, 8 Feb 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6672) EJB's async methods'
 Future#get should treat zero timeout as "don't wait"
In-Reply-To: <JIRA.12629585.1465048287000@Atlassian.JIRA>
References: <JIRA.12629585.1465048287000@Atlassian.JIRA>
	<JIRA.12629585.1465048287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629585.1465048287000.80457.1486562760755@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360371#comment-13360371 ] 

Daniel ?ih?k edited comment on WFLY-6672 at 2/8/17 9:05 AM:
------------------------------------------------------------

Pull request with test https://github.com/jbossas/jboss-eap7/pull/1282.


was (Author: dcihak):
Pull request with test https://github.com/wildfly/wildfly/pull/9617.

> EJB's async methods' Future#get should treat zero timeout as "don't wait"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6672
>                 URL: https://issues.jboss.org/browse/WFLY-6672
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Stuart Douglas
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> Say there is an asynchronous EJB method:
> {code}
> @Asynchronous
> public Future<Boolean> method() {
>    ...
> }
> {code}
> Calling Future#get with a zero timeout:
> {code}
> if (bean.method().get(0, TimeUnit.MILLISECONDS))
> {code}
> results in a block until the task is finished.
> Instead I expected zero waiting, because {{java.util.concurrent.Future.get(long, TimeUnit)}} doesn't specify any special treatment for a zero timeout value.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 09:07:01 2017
From: issues at jboss.org (=?UTF-8?Q?Daniel_=C4=8Cih=C3=A1k_=28JIRA=29?=)
Date: Wed, 8 Feb 2017 09:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6672) EJB's async methods'
 Future#get should treat zero timeout as "don't wait"
In-Reply-To: <JIRA.12629585.1465048287000@Atlassian.JIRA>
References: <JIRA.12629585.1465048287000@Atlassian.JIRA>
	<JIRA.12629585.1465048287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629585.1465048287000.80478.1486562821018@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360371#comment-13360371 ] 

Daniel ?ih?k edited comment on WFLY-6672 at 2/8/17 9:06 AM:
------------------------------------------------------------

Pull request with test https://github.com/wildfly/wildfly/pull/9617.


was (Author: dcihak):
Pull request with test https://github.com/jbossas/jboss-eap7/pull/1282.

> EJB's async methods' Future#get should treat zero timeout as "don't wait"
> -------------------------------------------------------------------------
>
>                 Key: WFLY-6672
>                 URL: https://issues.jboss.org/browse/WFLY-6672
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.2.0.Final
>            Reporter: Vsevolod Golovanov
>            Assignee: Stuart Douglas
>             Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> Say there is an asynchronous EJB method:
> {code}
> @Asynchronous
> public Future<Boolean> method() {
>    ...
> }
> {code}
> Calling Future#get with a zero timeout:
> {code}
> if (bean.method().get(0, TimeUnit.MILLISECONDS))
> {code}
> results in a block until the task is finished.
> Instead I expected zero waiting, because {{java.util.concurrent.Future.get(long, TimeUnit)}} doesn't specify any special treatment for a zero timeout value.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 09:11:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 8 Feb 2017 09:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.80506.1486563061388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved WFLY-7322.
------------------------------
    Resolution: Done


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 09:24:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 8 Feb 2017 09:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-31) CFME Tests: Adjust
 Datasource automation tests to 4.5 release.
In-Reply-To: <JIRA.12675545.1486563783000@Atlassian.JIRA>
References: <JIRA.12675545.1486563783000@Atlassian.JIRA>
	<JIRA.12675545.1486563783480@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675545.1486563783000.80590.1486563840389@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-31:
----------------------------------------

             Summary: 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  Wed Feb  8 09:25:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Wed, 8 Feb 2017 09:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1429) Validate DMN model `name`
 attributes to be valid FEEL name definition
In-Reply-To: <JIRA.12675548.1486563863000@Atlassian.JIRA>
References: <JIRA.12675548.1486563863000@Atlassian.JIRA>
	<JIRA.12675548.1486563863143@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675548.1486563863000.80602.1486563900159@Atlassian.JIRA>

Matteo Mortari created DROOLS-1429:
--------------------------------------

             Summary: Validate DMN model `name` attributes to be valid FEEL name definition
                 Key: DROOLS-1429
                 URL: https://issues.jboss.org/browse/DROOLS-1429
             Project: Drools
          Issue Type: Enhancement
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


The following xml example provide a case where the _decision_ name is not valid from a FEEL name definition perspective

{code:xml}
<definitions id="INVALID_NAME" name="INVALID_NAME" ...>
    <decision name="code in list of codes" id="d_GreetingMessage">
        <variable name="Greeting Message" typeRef="feel:string"/>
        <informationRequirement>
            <requiredInput href="#i_FullName"/>
        </informationRequirement>
        <literalExpression>
            <text>"Hello " + Full Name</text>
        </literalExpression>
    </decision>
    <inputData name="Full Name" id="i_FullName">
        <variable name="Full Name" typeRef="feel:string"/>
    </inputData>
</definitions>
{code}

and this case should be covered by the DMN Validation



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:16:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 10:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8057) Nonosecond precision lost in
 SqlTimestampExternalizer and InstantExternalizer
In-Reply-To: <JIRA.12675560.1486566948000@Atlassian.JIRA>
References: <JIRA.12675560.1486566948000@Atlassian.JIRA>
	<JIRA.12675560.1486566948863@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675560.1486566948000.81110.1486566960751@Atlassian.JIRA>

Radoslav Husar created WFLY-8057:
------------------------------------

             Summary: Nonosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
                 Key: WFLY-8057
                 URL: https://issues.jboss.org/browse/WFLY-8057
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase)  Time elapsed: 0.019 sec  <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)

Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase)  Time elapsed: 0.017 sec  <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)

Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase

Results :

Failed tests:
  TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
  DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>

Tests run: 9, Failures: 2, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:16:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 10:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8057) Nano precision lost in
 SqlTimestampExternalizer and InstantExternalizer
In-Reply-To: <JIRA.12675560.1486566949000@Atlassian.JIRA>
References: <JIRA.12675560.1486566949000@Atlassian.JIRA>
	<JIRA.12675560.1486566949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675560.1486566949000.81114.1486566960959@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8057:
---------------------------------
    Summary: Nano precision lost in SqlTimestampExternalizer and InstantExternalizer  (was: Nonosecond precision lost in SqlTimestampExternalizer and InstantExternalizer)


> Nano precision lost in SqlTimestampExternalizer and InstantExternalizer
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8057
>                 URL: https://issues.jboss.org/browse/WFLY-8057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase)  Time elapsed: 0.019 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)
> Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase)  Time elapsed: 0.017 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)
> Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Results :
> Failed tests:
>   TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
>   DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> Tests run: 9, Failures: 2, Errors: 0, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:17:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 10:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8057) Nanosecond precision lost in
 SqlTimestampExternalizer and InstantExternalizer
In-Reply-To: <JIRA.12675560.1486566949000@Atlassian.JIRA>
References: <JIRA.12675560.1486566949000@Atlassian.JIRA>
	<JIRA.12675560.1486566949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675560.1486566949000.81124.1486567020113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8057:
---------------------------------
    Summary: Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer  (was: Nano precision lost in SqlTimestampExternalizer and InstantExternalizer)


> Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-8057
>                 URL: https://issues.jboss.org/browse/WFLY-8057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase)  Time elapsed: 0.019 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)
> Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase)  Time elapsed: 0.017 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)
> Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Results :
> Failed tests:
>   TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
>   DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> Tests run: 9, Failures: 2, Errors: 0, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:22:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 10:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8058) Can't undefine attribute
 restart-jobs-on-resume in batch-jberet subsystem
In-Reply-To: <JIRA.12675562.1486567249000@Atlassian.JIRA>
References: <JIRA.12675562.1486567249000@Atlassian.JIRA>
	<JIRA.12675562.1486567249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675562.1486567249000.81153.1486567320419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins moved JBEAP-8736 to WFLY-8058:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8058  (was: JBEAP-8736)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Batch
                           (was: Batch)
    Affects Version/s:     (was: 7.1.0.DR11)


> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8058
>                 URL: https://issues.jboss.org/browse/WFLY-8058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: Dmitrii Tikhomirov
>            Priority: Minor
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> {noformat}
> Stack trace on server side: 
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 	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: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}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646755aace/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/BatchSubsystemDefinition.java#L159 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:23:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 10:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8058) Can't undefine attribute
 restart-jobs-on-resume in batch-jberet subsystem
In-Reply-To: <JIRA.12675562.1486567249000@Atlassian.JIRA>
References: <JIRA.12675562.1486567249000@Atlassian.JIRA>
	<JIRA.12675562.1486567249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675562.1486567249000.81164.1486567380470@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360524#comment-13360524 ] 

James Perkins commented on WFLY-8058:
-------------------------------------

[~treblereel] Are you working up a fix for this? If not I was going to do it quickly.

> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8058
>                 URL: https://issues.jboss.org/browse/WFLY-8058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: Dmitrii Tikhomirov
>            Priority: Minor
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> {noformat}
> Stack trace on server side: 
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 	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: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}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646755aace/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/BatchSubsystemDefinition.java#L159 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:25:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 10:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8057) Nanosecond precision lost in
 SqlTimestampExternalizer and InstantExternalizer
In-Reply-To: <JIRA.12675560.1486566949000@Atlassian.JIRA>
References: <JIRA.12675560.1486566949000@Atlassian.JIRA>
	<JIRA.12675560.1486566949000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675560.1486566949000.81180.1486567500118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8057:
---------------------------------
    Affects Version/s: 10.1.0.Final


> Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-8057
>                 URL: https://issues.jboss.org/browse/WFLY-8057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase)  Time elapsed: 0.019 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)
> Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
> test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase)  Time elapsed: 0.017 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> 	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
> 	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
> 	at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)
> Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
> Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
> Results :
> Failed tests:
>   TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
>   DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
> Tests run: 9, Failures: 2, Errors: 0, Skipped: 0
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.81190.1486567683734@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2264) Missing capability tab
 completion on object type attributes
In-Reply-To: <JIRA.12674939.1486233066000@Atlassian.JIRA>
References: <JIRA.12674939.1486233066000@Atlassian.JIRA>
	<JIRA.12674939.1486233066000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674939.1486233066000.81195.1486567683995@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2264:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> Missing capability tab completion on object type attributes
> -----------------------------------------------------------
>
>                 Key: WFCORE-2264
>                 URL: https://issues.jboss.org/browse/WFCORE-2264
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha22
>         Environment: Reproducible using current WildFly master
>            Reporter: Darran Lofthouse
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha25
>
>
> The following command is valid: -
> {{./core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=management-sasl-authentication)}}
> However tab completion is not possible to discover the available capabilities for the value.
> I suspect the dot notation to reference the sasl-authentication-factory sub attribute is not followed.
> (I am initially raising against the CLI but I don't know how the name parameter is handled here so could be a general management issue)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2249) ObjectTypeValidator only
 validates fields the user provides
In-Reply-To: <JIRA.12673993.1485882653000@Atlassian.JIRA>
References: <JIRA.12673993.1485882653000@Atlassian.JIRA>
	<JIRA.12673993.1485882653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673993.1485882653000.81198.1486567684125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2249:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> ObjectTypeValidator only validates fields the user provides
> -----------------------------------------------------------
>
>                 Key: WFCORE-2249
>                 URL: https://issues.jboss.org/browse/WFCORE-2249
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha25
>
>
> This in ObjectTypeValidator is wrong:
> {code}
>     @Override
>     public void validateParameter(final String parameterName, final ModelNode value) throws OperationFailedException {
>         super.validateParameter(parameterName, value);
>         if (value.isDefined()) {
>             for (String key : value.keys()) {
>                 if (allowedValues.containsKey(key)) {
>                     allowedValues.get(key).getValidator().validateParameter(key, value.get(key));
>                 } else {
>                     throw ROOT_LOGGER.invalidKeyForObjectType(key, parameterName);
>                 }
>             }
>         }
>     }
> {code}
> 1) It only iterates over the keys in 'value' so if value is missing any required fields that isn't detected.
> 2) It's not really appropriate to reject keys that are not part of the definition. The management code is meant to be forgiving in such cases.
> For now I think I'll just focus on #1. It's debatable whether being forgiving is really ideal in general, and since this particular bit of unforgivingness has been around since at least 2012 I think I'll leave it alone.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.81206.1486567684581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.81210.1486567684744@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha25, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Wed Feb  8 10:28:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.81217.1486567685084@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10: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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.81224.1486567685292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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  Wed Feb  8 10:28:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.81234.1486567685640@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.81243.1486567686020@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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 Feb  8 10:28:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.81250.1486567686379@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2025) CLI SSLContext Priority
In-Reply-To: <JIRA.12662781.1479732593000@Atlassian.JIRA>
References: <JIRA.12662781.1479732593000@Atlassian.JIRA>
	<JIRA.12662781.1479732593000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662781.1479732593000.81266.1486567687000@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2025:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> CLI SSLContext Priority
> -----------------------
>
>                 Key: WFCORE-2025
>                 URL: https://issues.jboss.org/browse/WFCORE-2025
>             Project: WildFly Core
>          Issue Type: Task
>          Components: CLI, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha25
>
>
> We have three different places an SSLContext could come from for the CLI: -
> # CLI Configuration
> # AuthenticationClient Configuration
> # Default interactive SSLContext
> We need to ensure they are prioritised as above.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.81258.1486567686689@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>         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  Wed Feb  8 10:28:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:07 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.81274.1486567687371@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.81277.1486567687539@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Alpha25
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.81290.1486567687906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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 Feb  8 10:28:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.81285.1486567687776@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1964:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Alpha25
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:28:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10: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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.81297.1486567688112@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.81303.1486567688458@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.81311.1486567688744@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:09 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.81322.1486567689124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Alpha25
>
>         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  Wed Feb  8 10:28:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:09 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.81331.1486567689325@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>         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  Wed Feb  8 10:28:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.81337.1486567689510@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.81341.1486567689612@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:28:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.81348.1486567689824@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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.<init>(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  Wed Feb  8 10:28:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 8 Feb 2017 10:28:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.81354.1486567690001@Atlassian.JIRA>


     [ 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.Alpha25
                       (was: 3.0.0.Alpha24)


> 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.Alpha25
>
>
> 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  Wed Feb  8 10:42:00 2017
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Wed, 8 Feb 2017 10:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1809) JBoss CLI patch command
 doesn't honor custom configuration location
In-Reply-To: <JIRA.12650999.1474372455000@Atlassian.JIRA>
References: <JIRA.12650999.1474372455000@Atlassian.JIRA>
	<JIRA.12650999.1474372455000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650999.1474372455000.81449.1486568520462@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Loubyansky closed WFCORE-1809.
-------------------------------------
    Resolution: Rejected


This is not going to be supported by the current patching mechanism.

> JBoss CLI patch command doesn't honor custom configuration location
> -------------------------------------------------------------------
>
>                 Key: WFCORE-1809
>                 URL: https://issues.jboss.org/browse/WFCORE-1809
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Patching 
>    Affects Versions: 3.0.0.Alpha8
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>
> Suppose we are using custom standalone directory(example: standalone_dev) and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch through management console and through JBoss CLI in connected mode. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:43:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 8 Feb 2017 10:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8059) Nanosecond precision lost in
 SqlTimestampExternalizer and InstantExternalizer
In-Reply-To: <JIRA.12675569.1486568575000@Atlassian.JIRA>
References: <JIRA.12675569.1486568575000@Atlassian.JIRA>
	<JIRA.12675569.1486568575265@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675569.1486568575000.81477.1486568580778@Atlassian.JIRA>

Radoslav Husar created WFLY-8059:
------------------------------------

             Summary: Nanosecond precision lost in SqlTimestampExternalizer and InstantExternalizer
                 Key: WFLY-8059
                 URL: https://issues.jboss.org/browse/WFLY-8059
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


This is evident with JDK fix for https://bugs.openjdk.java.net/browse/JDK-8068730

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in org.wildfly.clustering.marshalling.spi.IndexExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec - in org.wildfly.clustering.marshalling.spi.net.NetExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase)  Time elapsed: 0.019 sec  <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.time.TimeExternalizerTestCase.test(TimeExternalizerTestCase.java:54)

Running org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec - in org.wildfly.clustering.marshalling.spi.util.AtomicExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec - in org.wildfly.clustering.marshalling.spi.util.CollectionExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec <<< FAILURE! - in org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase
test(org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase)  Time elapsed: 0.017 sec  <<< FAILURE!
java.lang.AssertionError: expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>
	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.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.lambda$test$0(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:55)
	at org.wildfly.clustering.marshalling.spi.ExternalizerTestUtil.test(ExternalizerTestUtil.java:42)
	at org.wildfly.clustering.marshalling.spi.util.DateExternalizerTestCase.test(DateExternalizerTestCase.java:49)

Running org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.wildfly.clustering.marshalling.spi.util.MapEntryExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec - in org.wildfly.clustering.marshalling.spi.util.MapExternalizerTestCase
Running org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec - in org.wildfly.clustering.marshalling.spi.util.UtilExternalizerTestCase

Results :

Failed tests:
  TimeExternalizerTestCase.test:54 expected:<2017-02-08T11:02:48.240513Z> but was:<2017-02-08T11:02:48.240Z>
  DateExternalizerTestCase.test:49 expected:<2017-02-08 12:02:48.30185> but was:<2017-02-08 12:02:48.301>

Tests run: 9, Failures: 2, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:46:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Wed, 8 Feb 2017 10:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-6) Migrate API module from existent
	POC repo
In-Reply-To: <JIRA.12675570.1486568716000@Atlassian.JIRA>
References: <JIRA.12675570.1486568716000@Atlassian.JIRA>
	<JIRA.12675570.1486568716498@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675570.1486568716000.81540.1486568760641@Atlassian.JIRA>

Luis Barreiro created AG-6:
------------------------------

             Summary: Migrate API module from existent POC repo
                 Key: AG-6
                 URL: https://issues.jboss.org/browse/AG-6
             Project: Agroal
          Issue Type: Task
          Components: api
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro


Move the API code currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.

Rename packages and classes to io.agroal.api.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:52:00 2017
From: issues at jboss.org (Markus Heberling (JIRA))
Date: Wed, 8 Feb 2017 10:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-738) Ability to generate JUnits
 from WorkBench Test Scenarios
In-Reply-To: <JIRA.12565164.1425682089000@Atlassian.JIRA>
References: <JIRA.12565164.1425682089000@Atlassian.JIRA>
	<JIRA.12565164.1425682089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12565164.1425682089000.81624.1486569120378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360546#comment-13360546 ] 

Markus Heberling commented on DROOLS-738:
-----------------------------------------

With the upcoming JUnit5 it would not be necessary anymore to generate JUnit tests out of scenarios. It is possible to write a TestEngine, that can directly run the scenario files. I have started to work on such a TestEngine, maybe it is of use for someone who stumbles upon this future request. :)

https://github.com/tisoft/junit-drools-testscenario-engine

> Ability to generate JUnits from WorkBench Test Scenarios
> --------------------------------------------------------
>
>                 Key: DROOLS-738
>                 URL: https://issues.jboss.org/browse/DROOLS-738
>             Project: Drools
>          Issue Type: Feature Request
>          Components: tools
>    Affects Versions: 6.2.0.Final
>            Reporter: William DeCoste
>            Assignee: Mario Fusco
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:55:01 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 10:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8058) Can't undefine attribute
 restart-jobs-on-resume in batch-jberet subsystem
In-Reply-To: <JIRA.12675562.1486567249000@Atlassian.JIRA>
References: <JIRA.12675562.1486567249000@Atlassian.JIRA>
	<JIRA.12675562.1486567249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675562.1486567249000.81649.1486569301254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-8058:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9621


> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8058
>                 URL: https://issues.jboss.org/browse/WFLY-8058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> {noformat}
> Stack trace on server side: 
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 	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: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}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646755aace/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/BatchSubsystemDefinition.java#L159 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 10:55:01 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 10:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8058) Can't undefine attribute
 restart-jobs-on-resume in batch-jberet subsystem
In-Reply-To: <JIRA.12675562.1486567249000@Atlassian.JIRA>
References: <JIRA.12675562.1486567249000@Atlassian.JIRA>
	<JIRA.12675562.1486567249000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675562.1486567249000.81647.1486569301186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned WFLY-8058:
-----------------------------------

    Assignee: James Perkins  (was: Dmitrii Tikhomirov)


> Can't undefine attribute restart-jobs-on-resume in batch-jberet subsystem
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8058
>                 URL: https://issues.jboss.org/browse/WFLY-8058
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> {noformat}
> [standalone at localhost:9990 /] /subsystem=batch-jberet:undefine-attribute(name=restart-jobs-on-resume
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
>     "rolled-back" => true
> }
> {noformat}
> Stack trace on server side: 
> {noformat}
> 12:42:08,192 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("undefine-attribute") failed - address: ([("subsystem" => "batch-jberet")]): java.lang.IllegalArgumentException
> 	at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.setValue(BatchSubsystemDefinition.java:159)
> 	at org.wildfly.extension.batch.jberet.BatchSubsystemDefinition$1.applyUpdateToRuntime(BatchSubsystemDefinition.java:147)
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 	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: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}
> The problem is that the write handler of this attribute doesn't properly handle an undefined value: https://github.com/wildfly/wildfly/blob/9390551b93126e2216e49b4b02bc9f646755aace/batch/extension-jberet/src/main/java/org/wildfly/extension/batch/jberet/BatchSubsystemDefinition.java#L159 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 12:09:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 8 Feb 2017 12:09:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-31) CFME Tests: Adjust
 Datasource automation tests to 4.5 release.
In-Reply-To: <JIRA.12675545.1486563783000@Atlassian.JIRA>
References: <JIRA.12675545.1486563783000@Atlassian.JIRA>
	<JIRA.12675545.1486563783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675545.1486563783000.82424.1486573741295@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360627#comment-13360627 ] 

Hayk Hovsepyan commented on HAWKULARQE-31:
------------------------------------------

Blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1420431

> 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  Wed Feb  8 12:34:03 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 8 Feb 2017 12:34:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8060) Restore distributed SFSB
 cache key marshalling optimization
In-Reply-To: <JIRA.12675595.1486575223000@Atlassian.JIRA>
References: <JIRA.12675595.1486575223000@Atlassian.JIRA>
	<JIRA.12675595.1486575223000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675595.1486575223000.82609.1486575243097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-8739 to WFLY-8060:
-------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8060  (was: JBEAP-8739)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Clustering
                 EJB
                     (was: Clustering)
                     (was: EJB)


> Restore distributed SFSB cache key marshalling optimization
> -----------------------------------------------------------
>
>                 Key: WFLY-8060
>                 URL: https://issues.jboss.org/browse/WFLY-8060
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> As part of EAP7-552, EJBs use a new SessionID implementation for which we don't currently have an externalizer.  This causes Infinispan to unnecessarily marshal and send class descriptors for each cache operation.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 12:35:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 8 Feb 2017 12:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8060) Restore distributed SFSB
 cache key marshalling optimization
In-Reply-To: <JIRA.12675595.1486575223000@Atlassian.JIRA>
References: <JIRA.12675595.1486575223000@Atlassian.JIRA>
	<JIRA.12675595.1486575223000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675595.1486575223000.82613.1486575300159@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8060:
-------------------------------
    Affects Version/s: No Release


> Restore distributed SFSB cache key marshalling optimization
> -----------------------------------------------------------
>
>                 Key: WFLY-8060
>                 URL: https://issues.jboss.org/browse/WFLY-8060
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: No Release
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> As part of EAP7-552, EJBs use a new SessionID implementation for which we don't currently have an externalizer.  This causes Infinispan to unnecessarily marshal and send class descriptors for each cache operation.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 13:04:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Wed, 8 Feb 2017 13:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8061) Support role mapping from
 jboss deployment descriptors in undertow subsystem
In-Reply-To: <JIRA.12675604.1486577000000@Atlassian.JIRA>
References: <JIRA.12675604.1486577000000@Atlassian.JIRA>
	<JIRA.12675604.1486577000363@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675604.1486577000000.82859.1486577040877@Atlassian.JIRA>

Pedro Igor created WFLY-8061:
--------------------------------

             Summary: Support role mapping from jboss deployment descriptors in undertow subsystem
                 Key: WFLY-8061
                 URL: https://issues.jboss.org/browse/WFLY-8061
             Project: WildFly
          Issue Type: Enhancement
          Components: Security, Web (Undertow)
            Reporter: Pedro Igor
            Assignee: Darran Lofthouse


Currently, role mapping from jboss-web.xml and jboss-app.xml are not taken into consideration when mapping roles for an identity in Elytron.

This already being done by ejb subsystem, but we lack in web/undertow subsystem.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 13:55:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 13:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8062) Some OSH's in the Elytron
 subsystem don't validate the server type before registering steps
In-Reply-To: <JIRA.12675608.1486580041000@Atlassian.JIRA>
References: <JIRA.12675608.1486580041000@Atlassian.JIRA>
	<JIRA.12675608.1486580041298@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675608.1486580041000.83217.1486580100293@Atlassian.JIRA>

James Perkins created WFLY-8062:
-----------------------------------

             Summary: Some OSH's in the Elytron subsystem don't validate the server type before registering steps
                 Key: WFLY-8062
                 URL: https://issues.jboss.org/browse/WFLY-8062
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Blocker
             Fix For: 11.0.0.Alpha1


In the Elytron subsystem there are implementations of {{org.jboss.as.controller.OperationStepHandler}} that do not check the state of the {{OperationContext}} before registering runtime steps. This is an issue for domain servers as the steps will be registered on the host-controller even if the operations is being executed on a profile.

For example:
{code:java}
@Override
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
    context.addStep(operation, (parentContext, parentOperation) -> {
        ModifiableRealmIdentity realmIdentity = getRealmIdentity(parentContext);
        List<ModelNode> modelNodes = parentOperation.asList();
        Property passwordProperty = modelNodes.get(2).asProperty();
        PathAddress currentAddress = parentContext.getCurrentAddress();
        String principalName = currentAddress.getLastElement().getValue();

        try {
            realmIdentity.setCredentials(Collections.singleton(new PasswordCredential(createPassword(parentContext, principalName, passwordProperty))));
        } catch (NoSuchAlgorithmException | InvalidKeySpecException | RealmUnavailableException e) {
            throw ROOT_LOGGER.couldNotCreatePassword(e);
        }
        parentContext.completeStep(NOOP_RESULT_HANDLER);
    }, OperationContext.Stage.RUNTIME);
}
{code}

Should check the {{context.isDefaultRequiresRuntime()}}:
{code:java}
@Override
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
    if (context.isDefaultRequiresRuntime()) {
        context.addStep(operation, (parentContext, parentOperation) -> {
            ModifiableRealmIdentity realmIdentity = getRealmIdentity(parentContext);
            List<ModelNode> modelNodes = parentOperation.asList();
            Property passwordProperty = modelNodes.get(2).asProperty();
            PathAddress currentAddress = parentContext.getCurrentAddress();
            String principalName = currentAddress.getLastElement().getValue();

            try {
                realmIdentity.setCredentials(Collections.singleton(new PasswordCredential(createPassword(parentContext, principalName, passwordProperty))));
            } catch (NoSuchAlgorithmException | InvalidKeySpecException | RealmUnavailableException e) {
                throw ROOT_LOGGER.couldNotCreatePassword(e);
            }
            parentContext.completeStep(NOOP_RESULT_HANDLER);
        }, OperationContext.Stage.RUNTIME);
    }
}
{code}

The handlers should be analyzed to ensure they check the state before registering runtime steps.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 14:32:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Wed, 8 Feb 2017 14:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7796) Java EE 7 API: Bug in
	javaee-api-7.0.jar
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.83652.1486582320693@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-7796:
----------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Farah Juma)


> Java EE 7 API: Bug in javaee-api-7.0.jar
> ----------------------------------------
>
>                 Key: WFLY-7796
>                 URL: https://issues.jboss.org/browse/WFLY-7796
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 10.1.0.Final
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 14:32:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Wed, 8 Feb 2017 14:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7796) Java EE 7 API: unable to
 validate expressions with method invocations
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.83659.1486582320991@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov updated WFLY-7796:
-------------------------------------
    Summary: Java EE 7 API: unable to validate expressions with method invocations  (was: Java EE 7 API: Bug in javaee-api-7.0.jar)


> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7796
>                 URL: https://issues.jboss.org/browse/WFLY-7796
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 10.1.0.Final
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 14:34:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Wed, 8 Feb 2017 14:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7796) Java EE 7 API: unable to
 validate expressions with method invocations
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.83678.1486582440695@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360738#comment-13360738 ] 

Dmitrii Tikhomirov commented on WFLY-7796:
------------------------------------------

proposed solution:  https://github.com/treblereel/jboss-jsf-api_spec/commit/19738f4eadf2987b160e2a9eceff4ae3fa25cd55

> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
>                 Key: WFLY-7796
>                 URL: https://issues.jboss.org/browse/WFLY-7796
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 10.1.0.Final
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 14:35:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 8 Feb 2017 14:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8063) When a looked up service is
 modified it should use the OperationContext.getServiceRegistry(true)
In-Reply-To: <JIRA.12675619.1486582446000@Atlassian.JIRA>
References: <JIRA.12675619.1486582446000@Atlassian.JIRA>
	<JIRA.12675619.1486582446085@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675619.1486582446000.83694.1486582500862@Atlassian.JIRA>

James Perkins created WFLY-8063:
-----------------------------------

             Summary: When a looked up service is modified it should use the OperationContext.getServiceRegistry(true)
                 Key: WFLY-8063
                 URL: https://issues.jboss.org/browse/WFLY-8063
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: James Perkins
            Assignee: James Perkins


In cases where a service is looked up in the {{OperationContext.getServiceRegistry()}} and the service is modified the registry should be looked up with {{true}} for the modifiable parameter.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 14:40:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Wed, 8 Feb 2017 14:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1430) DMN Model nodes to
 reference origin XML location, also to improve Validation
In-Reply-To: <JIRA.12675620.1486582794000@Atlassian.JIRA>
References: <JIRA.12675620.1486582794000@Atlassian.JIRA>
	<JIRA.12675620.1486582794764@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675620.1486582794000.83767.1486582800323@Atlassian.JIRA>

Matteo Mortari created DROOLS-1430:
--------------------------------------

             Summary: DMN Model nodes to reference origin XML location, also to improve Validation
                 Key: DROOLS-1430
                 URL: https://issues.jboss.org/browse/DROOLS-1430
             Project: Drools
          Issue Type: Enhancement
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


For each DMN Model node provide the XML origin. This shall in turn provide more helpful information during DMN Validation.

This also requires for the validation rules to always reference the original source model object



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 15:15:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Feb 2017 15:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2278) credential-reference not
 able to use masked passwords
In-Reply-To: <JIRA.12675627.1486584872000@Atlassian.JIRA>
References: <JIRA.12675627.1486584872000@Atlassian.JIRA>
	<JIRA.12675627.1486584872499@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675627.1486584872000.83976.1486584900188@Atlassian.JIRA>

Peter Skopek created WFCORE-2278:
------------------------------------

             Summary: credential-reference not able to use masked passwords
                 Key: WFCORE-2278
                 URL: https://issues.jboss.org/browse/WFCORE-2278
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
    Affects Versions: 3.0.0.Alpha24
            Reporter: Peter Skopek
            Assignee: Peter Skopek
            Priority: Blocker


credential-reference cannot use PBE encrypted credentials AKA masked passwords (MASK-). 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 15:18:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 8 Feb 2017 15:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2278) credential-reference not
 able to use masked passwords
In-Reply-To: <JIRA.12675627.1486584872000@Atlassian.JIRA>
References: <JIRA.12675627.1486584872000@Atlassian.JIRA>
	<JIRA.12675627.1486584872000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675627.1486584872000.84003.1486585080310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360756#comment-13360756 ] 

Peter Skopek commented on WFCORE-2278:
--------------------------------------

There was way to use masked passwords introduced, but decryption on the elytron side has changed.
For now, we decided to go with PicketBox compatible and simple enough algorithm.

> credential-reference not able to use masked passwords
> -----------------------------------------------------
>
>                 Key: WFCORE-2278
>                 URL: https://issues.jboss.org/browse/WFCORE-2278
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 3.0.0.Alpha24
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>            Priority: Blocker
>
> credential-reference cannot use PBE encrypted credentials AKA masked passwords (MASK-). 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 15:28:00 2017
From: issues at jboss.org (Jeremy Whiting (JIRA))
Date: Wed, 8 Feb 2017 15:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4889) JSF application without CDI
 causes Undertow to crash on deployment
In-Reply-To: <JIRA.12577442.1436372123000@Atlassian.JIRA>
References: <JIRA.12577442.1436372123000@Atlassian.JIRA>
	<JIRA.12577442.1436372123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577442.1436372123000.84056.1486585680302@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360762#comment-13360762 ] 

Jeremy Whiting commented on WFLY-4889:
--------------------------------------

A workaround is to add an empty beans.xml file to the archive.

> JSF application without CDI causes Undertow to crash on deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4889
>                 URL: https://issues.jboss.org/browse/WFLY-4889
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.0.Final
>            Reporter: Ken Finnigan
>            Assignee: Farah Juma
>
> My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required.
> If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> 	at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084)
> 	at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key  {{javax.faces.validator.beanValidator.ValidatorFactory}}.
> I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFBeanValidationFactoryProcessor.java adding the validation factory as a servlet context attribute whether the retrieval found one or not.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 15:34:00 2017
From: issues at jboss.org (Johnathon Lee (JIRA))
Date: Wed, 8 Feb 2017 15:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7196) The outcome of xa_commit call
 on non exiting transaction is silently ignored
In-Reply-To: <JIRA.12651512.1474554307000@Atlassian.JIRA>
References: <JIRA.12651512.1474554307000@Atlassian.JIRA>
	<JIRA.12651512.1474554307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651512.1474554307000.84102.1486586040337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnathon Lee updated WFLY-7196:
--------------------------------


> The outcome of xa_commit call on non exiting transaction is silently ignored
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-7196
>                 URL: https://issues.jboss.org/browse/WFLY-7196
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Tom Ross
>            Assignee: Flavia Rainone
>
> This is from mail thread on transactional mailing list:
> {noformat}
> There is definitely a bug in EJBR.
> These two at least look wrong by inspection:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionPrepareTask.java#L100
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/remote/protocol/versionone/XidTransactionCommitTask.java#L68
> The way they are implemented means that when the transaction manager calls commit/prepare on an Xid if there is no transaction at the remote side EJBR just ignores the problem whereas it needs to return an XA error so the TM knows about it.
> You could simulate this with a test case that gets hold of the EJBR XAResource and invokes:
> xar.prepare(dummyXid) and does not get back XAER_NOTA
> That explains how the root transaction can prepare/commit without error as we can see here:
> 2016-09-12 16:04:02,303 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext at 18d6826a, nodeName='svc-2-presentation', state=State{transactionID=org.jboss.ejb.client.XidTransactionID at 303ce194, suspended=false, participantCnt=0}}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> 2016-09-12 16:04:02,364 TRACE [com.arjuna.ats.jta] (EJB async - 8) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:ResourceImpl{transactionKey=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, ejbClientContext=org.jboss.ejb.client.EJBClientContext at 18d6826a, nodeName='svc-2-presentation', state=null}, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f2e, node_name=svc_2_presentation, branch_uid=0:ffff0af7f6b6:6b296e38:57d14447:63f4a, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 1754f10f >, record id=0:ffff0af7f6b6:6b296e38:57d14447:63f4b
> Both those lines I indicated above have debug statements but they should be ERROR and return appropriate XA exceptions.
> What it does not explain is why the transaction is initially imported 45 minutes later. I guess it is stuck in some EJB processing queue.
> What I think needs curing first is the data integrity issue (i.e. silently ignoring if there is no imported transaction) in the EJB remoting transport. That should be relatively easy as EJBR can just return appropriate errors when it can't find the imported transaction. This part should be tackled urgently.
> After that the strange error where the import is processed late should be tackled but I am not familiar enough with the EJB remoting async architecture to suggest how to proceed with that.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 16:12:00 2017
From: issues at jboss.org (Jeremy Whiting (JIRA))
Date: Wed, 8 Feb 2017 16:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4889) JSF application without CDI
 causes Undertow to crash on deployment
In-Reply-To: <JIRA.12577442.1436372123000@Atlassian.JIRA>
References: <JIRA.12577442.1436372123000@Atlassian.JIRA>
	<JIRA.12577442.1436372123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577442.1436372123000.84231.1486588320390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Whiting updated WFLY-4889:
---------------------------------
    Comment: was deleted

(was: A workaround is to add an empty beans.xml file to the archive.)


> JSF application without CDI causes Undertow to crash on deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4889
>                 URL: https://issues.jboss.org/browse/WFLY-4889
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.0.Final
>            Reporter: Ken Finnigan
>            Assignee: Farah Juma
>
> My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required.
> If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> 	at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084)
> 	at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key  {{javax.faces.validator.beanValidator.ValidatorFactory}}.
> I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFBeanValidationFactoryProcessor.java adding the validation factory as a servlet context attribute whether the retrieval found one or not.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 16:35:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Feb 2017 16:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-171) Java EE 7 API: unable to
 validate expressions with method invocations
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.84343.1486589700271@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved WFLY-7796 to JBEE-171:
----------------------------------------

              Project: JBoss JavaEE Spec APIs  (was: WildFly)
                  Key: JBEE-171  (was: WFLY-7796)
             Workflow: classic default workflow  (was: GIT Pull Request workflow )
          Component/s: jboss-jsf-api
                           (was: JSF)
    Affects Version/s:     (was: 10.1.0.Final)


> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
>                 Key: JBEE-171
>                 URL: https://issues.jboss.org/browse/JBEE-171
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 16:35:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Feb 2017 16:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-171) Java EE 7 API: unable to
 validate expressions with method invocations
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.84349.1486589700467@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360793#comment-13360793 ] 

Tomaz Cerar commented on JBEE-171:
----------------------------------

solutions looks ok.

> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
>                 Key: JBEE-171
>                 URL: https://issues.jboss.org/browse/JBEE-171
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb  8 16:37:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 8 Feb 2017 16:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4889) JSF application without CDI
 causes Undertow to crash on deployment
In-Reply-To: <JIRA.12577442.1436372123000@Atlassian.JIRA>
References: <JIRA.12577442.1436372123000@Atlassian.JIRA>
	<JIRA.12577442.1436372123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577442.1436372123000.84362.1486589820809@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360795#comment-13360795 ] 

Tomaz Cerar commented on WFLY-4889:
-----------------------------------

Is this still the case with WildFly 10?

> JSF application without CDI causes Undertow to crash on deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4889
>                 URL: https://issues.jboss.org/browse/WFLY-4889
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.0.Final
>            Reporter: Ken Finnigan
>            Assignee: Farah Juma
>
> My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required.
> If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> 	at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084)
> 	at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key  {{javax.faces.validator.beanValidator.ValidatorFactory}}.
> I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFBeanValidationFactoryProcessor.java adding the validation factory as a servlet context attribute whether the retrieval found one or not.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 16:39:00 2017
From: issues at jboss.org (Ken Finnigan (JIRA))
Date: Wed, 8 Feb 2017 16:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4889) JSF application without CDI
 causes Undertow to crash on deployment
In-Reply-To: <JIRA.12577442.1436372123000@Atlassian.JIRA>
References: <JIRA.12577442.1436372123000@Atlassian.JIRA>
	<JIRA.12577442.1436372123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577442.1436372123000.84395.1486589940712@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360798#comment-13360798 ] 

Ken Finnigan commented on WFLY-4889:
------------------------------------

>From looking at the same code in WF 10, it looks like it now checks whether one is found before adding the attachment.

So can close as resolved in WF 10

> JSF application without CDI causes Undertow to crash on deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4889
>                 URL: https://issues.jboss.org/browse/WFLY-4889
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.0.Final
>            Reporter: Ken Finnigan
>            Assignee: Farah Juma
>
> My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required.
> If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> 	at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084)
> 	at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key  {{javax.faces.validator.beanValidator.ValidatorFactory}}.
> I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFBeanValidationFactoryProcessor.java adding the validation factory as a servlet context attribute whether the retrieval found one or not.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 16:52:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 8 Feb 2017 16:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4889) JSF application without CDI
 causes Undertow to crash on deployment
In-Reply-To: <JIRA.12577442.1436372123000@Atlassian.JIRA>
References: <JIRA.12577442.1436372123000@Atlassian.JIRA>
	<JIRA.12577442.1436372123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12577442.1436372123000.84479.1486590720667@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-4889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma resolved WFLY-4889.
------------------------------
    Fix Version/s: 10.0.0.Final
       Resolution: Out of Date


> JSF application without CDI causes Undertow to crash on deployment
> ------------------------------------------------------------------
>
>                 Key: WFLY-4889
>                 URL: https://issues.jboss.org/browse/WFLY-4889
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 9.0.0.Final
>            Reporter: Ken Finnigan
>            Assignee: Farah Juma
>             Fix For: 10.0.0.Final
>
>
> My understanding of the JSF spec is that CDI is not a requirement for JSF to function, though there may be some parts of CDI that are required.
> If I deploy a very simple JSF app to Undertow without CDI, I get the following stack trace:
> {noformat}
> Caused by: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> 	at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:1084)
> 	at io.undertow.servlet.spec.ServletContextImpl.<init>(ServletContextImpl.java:128)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:148)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> 	... 6 more
> {noformat}
> From debugging the value being {{put}} that causes the NPE, it is attempting to add a value of {{null}} for the key  {{javax.faces.validator.beanValidator.ValidatorFactory}}.
> I believe this is a result of https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFBeanValidationFactoryProcessor.java adding the validation factory as a servlet context attribute whether the retrieval found one or not.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 17:38:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 8 Feb 2017 17:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1777) Use separate resources for
 GET requests involving useStreamAsResponse
In-Reply-To: <JIRA.12649505.1473438511000@Atlassian.JIRA>
References: <JIRA.12649505.1473438511000@Atlassian.JIRA>
	<JIRA.12649505.1473438511000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649505.1473438511000.84763.1486593480450@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1777:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha25
                   2.2.1.Final
                       (was: 3.0.0.CR1)


> Use separate resources for GET requests involving useStreamAsResponse
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-1777
>                 URL: https://issues.jboss.org/browse/WFCORE-1777
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha25, 2.2.1.Final
>
>
> A request for streamed content can potentially involve a large amount of content, e.g. a very large log file. We should limit the amount of resources (e.g. threads) available for handling such HTTP requests over the /management context, particularly in the case of GET requests where we don't do the cross-origin checks that  we do with POST.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 17:48:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 8 Feb 2017 17:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2279) Read resource operation
 handler does not preserve child order when registration has model overrides
In-Reply-To: <JIRA.12675655.1486594027000@Atlassian.JIRA>
References: <JIRA.12675655.1486594027000@Atlassian.JIRA>
	<JIRA.12675655.1486594027380@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675655.1486594027000.84830.1486594080149@Atlassian.JIRA>

Paul Ferraro created WFCORE-2279:
------------------------------------

             Summary: Read resource operation handler does not preserve child order when registration has model overrides
                 Key: WFCORE-2279
                 URL: https://issues.jboss.org/browse/WFCORE-2279
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.0.Alpha24
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Critical


Normally, the read resource operation returns children of a given type in their correct order. However, if the child type has overrides (e.g. type=foo overrides type=*), the read resource operation returns the override children first, followed by the wildcard children in order.  Order should be respected for all children of a given type.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 22:46:00 2017
From: issues at jboss.org (Bui Van Nghiem (JIRA))
Date: Wed, 8 Feb 2017 22:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4748) Singleton service fails to
 start after repetitive cluster split with "Failed to reach quorum of 1"
In-Reply-To: <JIRA.12573978.1433492548000@Atlassian.JIRA>
References: <JIRA.12573978.1433492548000@Atlassian.JIRA>
	<JIRA.12573978.1433492548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573978.1433492548000.85072.1486611960675@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360852#comment-13360852 ] 

Bui Van Nghiem commented on WFLY-4748:
--------------------------------------

I still face the same error on WildFly 9.0.2 after Full GC on master server:
2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "axs-application-server-deployment-9.6.90-346143" service. No singleton master will be elected. 

> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4748
>                 URL: https://issues.jboss.org/browse/WFLY-4748
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
>     // ...
>     for (Listener listener: this.listeners) {
>         listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
>     }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 22:47:00 2017
From: issues at jboss.org (Bui Van Nghiem (JIRA))
Date: Wed, 8 Feb 2017 22:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4748) Singleton service fails to
 start after repetitive cluster split with "Failed to reach quorum of 1"
In-Reply-To: <JIRA.12573978.1433492548000@Atlassian.JIRA>
References: <JIRA.12573978.1433492548000@Atlassian.JIRA>
	<JIRA.12573978.1433492548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573978.1433492548000.85078.1486612020185@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360852#comment-13360852 ] 

Bui Van Nghiem edited comment on WFLY-4748 at 2/8/17 10:46 PM:
---------------------------------------------------------------

I still face the same error on WildFly 9.0.2 after Full GC on master server:
2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "my-service" service. No singleton master will be elected. 


was (Author: bvnghiem1012):
I still face the same error on WildFly 9.0.2 after Full GC on master server:
2017-02-07 16:00:00,188 ERROR [stateTransferExecutor-thread--p18-t2]-[org.wildfly.clustering.server] WFLYCLSV0006: Failed to reach quorum of 1 for "axs-application-server-deployment-9.6.90-346143" service. No singleton master will be elected. 

> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4748
>                 URL: https://issues.jboss.org/browse/WFLY-4748
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
>     // ...
>     for (Listener listener: this.listeners) {
>         listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
>     }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb  8 22:50:00 2017
From: issues at jboss.org (Bui Van Nghiem (JIRA))
Date: Wed, 8 Feb 2017 22:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4748) Singleton service fails to
 start after repetitive cluster split with "Failed to reach quorum of 1"
In-Reply-To: <JIRA.12573978.1433492548000@Atlassian.JIRA>
References: <JIRA.12573978.1433492548000@Atlassian.JIRA>
	<JIRA.12573978.1433492548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573978.1433492548000.85086.1486612200208@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360855#comment-13360855 ] 

Bui Van Nghiem commented on WFLY-4748:
--------------------------------------

 https://github.com/wildfly/wildfly/pull/7685 is not merged to 9.x branch

> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4748
>                 URL: https://issues.jboss.org/browse/WFLY-4748
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
>     // ...
>     for (Listener listener: this.listeners) {
>         listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
>     }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 04:01:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Thu, 9 Feb 2017 04:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4748) Singleton service fails to
 start after repetitive cluster split with "Failed to reach quorum of 1"
In-Reply-To: <JIRA.12573978.1433492548000@Atlassian.JIRA>
References: <JIRA.12573978.1433492548000@Atlassian.JIRA>
	<JIRA.12573978.1433492548000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573978.1433492548000.85621.1486630860552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360913#comment-13360913 ] 

Tomas Hofman commented on WFLY-4748:
------------------------------------

[~bvnghiem1012] you will have to use Wildfly 10 to have this fixed.

> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4748
>                 URL: https://issues.jboss.org/browse/WFLY-4748
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
>            Reporter: Tomas Hofman
>            Assignee: Paul Ferraro
>             Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
>     // ...
>     for (Listener listener: this.listeners) {
>         listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
>     }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 04:44:00 2017
From: issues at jboss.org (Markus Pollak (JIRA))
Date: Thu, 9 Feb 2017 04:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-171) Java EE 7 API: unable to
 validate expressions with method invocations
In-Reply-To: <JIRA.12667602.1481718457000@Atlassian.JIRA>
References: <JIRA.12667602.1481718457000@Atlassian.JIRA>
	<JIRA.12667602.1481718457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667602.1481718457000.85894.1486633440383@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360944#comment-13360944 ] 

Markus Pollak commented on JBEE-171:
------------------------------------

The solution is fine.

> Java EE 7 API: unable to validate expressions with method invocations
> ---------------------------------------------------------------------
>
>                 Key: JBEE-171
>                 URL: https://issues.jboss.org/browse/JBEE-171
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jsf-api
>            Reporter: Markus Pollak
>            Assignee: Dmitrii Tikhomirov
>
> Hello,
> I?ve found a bug in the javaee-api-7.0.jar:
> *Problem:*
> javax.faces.validator.ValueExpressionAnalyzer$InterceptingResolver should also override (and delegate) the method "invoke" from ELResolver otherwise the BeanValidator wouldn?t support expressions with method invocations (e.g. #{exampleBean.anyMethod(anyParam).value}. Currently it doesn?t override the method so the default implementation is taken which returns null and leads to problems?
> Best Regards,
> Markus Pollak 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb  9 05:24:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 9 Feb 2017 05:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1312) Maven plug-in to auto
 instrument bytecode for OOPath reactivity
In-Reply-To: <JIRA.12652514.1475141765000@Atlassian.JIRA>
References: <JIRA.12652514.1475141765000@Atlassian.JIRA>
	<JIRA.12652514.1475141765000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12652514.1475141765000.86194.1486635840050@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13360975#comment-13360975 ] 

Matteo Mortari commented on DROOLS-1312:
----------------------------------------

This was documented with https://github.com/droolsjbpm/kie-docs/commit/9c1296ac29a1ac7a18aade711a49c399f5a1a166#diff-e9cdde97c6ab0c1f71ee977d31aabece

> Maven plug-in to auto instrument bytecode for OOPath reactivity
> ---------------------------------------------------------------
>
>                 Key: DROOLS-1312
>                 URL: https://issues.jboss.org/browse/DROOLS-1312
>             Project: Drools
>          Issue Type: Feature Request
>          Components: tools
>    Affects Versions: 6.5.0.CR2
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>            Priority: Minor
>             Fix For: 7.0.0.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 05:31:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 9 Feb 2017 05:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1303) OOPath reactive Collection
	coverage
In-Reply-To: <JIRA.12651491.1474549478000@Atlassian.JIRA>
References: <JIRA.12651491.1474549478000@Atlassian.JIRA>
	<JIRA.12651491.1474549478000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651491.1474549478000.86226.1486636260296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari resolved DROOLS-1303.
------------------------------------
    Fix Version/s: 7.0.0.Beta5
       Resolution: Done


Done with:
* https://github.com/droolsjbpm/drools/commit/20611a8ecac04da5034ce08d04520cd122362f5a
* https://github.com/droolsjbpm/droolsjbpm-integration/commit/a02acc8888817d4fc744b4ac157a8f49595c2b47
* https://github.com/droolsjbpm/kie-docs/commit/9c1296ac29a1ac7a18aade711a49c399f5a1a166

> OOPath reactive Collection coverage
> -----------------------------------
>
>                 Key: DROOLS-1303
>                 URL: https://issues.jboss.org/browse/DROOLS-1303
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.CR2
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>             Fix For: 7.0.0.Beta5
>
>
> * proper coverage for all methods of java.util.Collection e.g.: addAll()



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 05:58:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 9 Feb 2017 05:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-903) Missing some role assignment
 for Elytron ldap-realm when role and user are members of the same role
In-Reply-To: <JIRA.12674123.1485949333000@Atlassian.JIRA>
References: <JIRA.12674123.1485949333000@Atlassian.JIRA>
	<JIRA.12674123.1485949333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674123.1485949333000.86450.1486637880542@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361009#comment-13361009 ] 

Jan Kalina commented on ELY-903:
--------------------------------

Resolved by replacing depth first search (using recursion) by breadth first search (using queue and cycle).

> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
>                 Key: ELY-903
>                 URL: https://issues.jboss.org/browse/ELY-903
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
> The same behavior occurs when role mapping is configured in application server in opposite way (principal to group mapping which uses memberOf attribute).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 06:36:00 2017
From: issues at jboss.org (Pradeep Ganapathy (JIRA))
Date: Thu, 9 Feb 2017 06:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8064) Dependecy Injection not
	working
In-Reply-To: <JIRA.12675715.1486640122000@Atlassian.JIRA>
References: <JIRA.12675715.1486640122000@Atlassian.JIRA>
	<JIRA.12675715.1486640122554@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675715.1486640122000.86671.1486640160345@Atlassian.JIRA>

Pradeep Ganapathy created WFLY-8064:
---------------------------------------

             Summary: Dependecy Injection not working
                 Key: WFLY-8064
                 URL: https://issues.jboss.org/browse/WFLY-8064
             Project: WildFly
          Issue Type: Release
          Components: CDI / Weld
    Affects Versions: 10.0.0.Final
         Environment: Windows 2012 R2
            Reporter: Pradeep Ganapathy
            Assignee: Stuart Douglas


All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception

RestEasy versions(All) ----> 3.0.14.Final.

ApplicationScoped
public class TestImpl implements ITest
{
  
  @Inject
 private ITestDAO dao;

  public TestImpl setTestDAO(ITestDAO dao)
  {
   this.dao = dao;
   return this;
  }

  @Inject 
private TestDescription testDescription;

  public TestImpl setTestDescription(TestDescription testDescription)
  {
   this.testDescription = testDescription;
   return this;
  }
}


Error Logs:

2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException

Caused by: java.lang.NullPointerException
  at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
  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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
  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:395)
  ... 35 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 07:33:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 9 Feb 2017 07:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2271) CLI should use Endpoint
	executor
In-Reply-To: <JIRA.12675351.1486486620000@Atlassian.JIRA>
References: <JIRA.12675351.1486486620000@Atlassian.JIRA>
	<JIRA.12675351.1486486620000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675351.1486486620000.87034.1486643580548@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361080#comment-13361080 ] 

Jean-Francois Denise commented on WFCORE-2271:
----------------------------------------------

Implementation in private branch: https://github.com/jfdenise/wildfly-core/commit/82343adc9d07b5f2b5054a1ab72511680c257418


> CLI should use Endpoint executor
> --------------------------------
>
>                 Key: WFCORE-2271
>                 URL: https://issues.jboss.org/browse/WFCORE-2271
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> Today the 16 threads (default value) of the ThreadPool attached to the Endpoint are started and never used (except during connection of Controller client).
> CLI, instead of instantiating and managing its own Executor, it should re-use the XNIO one and configure its size the way the CLI custom one does.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 07:34:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 9 Feb 2017 07:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2272) Ctrl-C sent on command
 taking long time doesn't cancel the current operation
In-Reply-To: <JIRA.12675363.1486489054000@Atlassian.JIRA>
References: <JIRA.12675363.1486489054000@Atlassian.JIRA>
	<JIRA.12675363.1486489054000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675363.1486489054000.87050.1486643640695@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361082#comment-13361082 ] 

Jean-Francois Denise commented on WFCORE-2272:
----------------------------------------------

Implementation in private branch: https://github.com/jfdenise/wildfly-core/commit/396713ed65c51fb1fc9b46da4798828e9f069e20

> Ctrl-C sent on command taking long time doesn't cancel the current operation
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-2272
>                 URL: https://issues.jboss.org/browse/WFCORE-2272
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> For example, during a deploy that takes time, a user types Ctrl-C, this does unlock the prompt and the command "seems" to have been interrupted. Actually the command thread has been interrupted but not the remoting task that is in progress. So although the user can think its command has been aborted, it is silently processing in background.
> When interruption occurs in a command thread, current remoting task should be canceled. This is what we are doing today when a timeout is set on a command.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 07:36:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 9 Feb 2017 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2272) Ctrl-C sent on command
 taking long time doesn't cancel the current operation
In-Reply-To: <JIRA.12675363.1486489054000@Atlassian.JIRA>
References: <JIRA.12675363.1486489054000@Atlassian.JIRA>
	<JIRA.12675363.1486489054000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675363.1486489054000.87065.1486643760609@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361085#comment-13361085 ] 

Jean-Francois Denise commented on WFCORE-2272:
----------------------------------------------

Whatever the timeout being set or not, DMR requests are asynchronous. The running task is kept, ready to be canceled if Interrupt occurs.

> Ctrl-C sent on command taking long time doesn't cancel the current operation
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-2272
>                 URL: https://issues.jboss.org/browse/WFCORE-2272
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> For example, during a deploy that takes time, a user types Ctrl-C, this does unlock the prompt and the command "seems" to have been interrupted. Actually the command thread has been interrupted but not the remoting task that is in progress. So although the user can think its command has been aborted, it is silently processing in background.
> When interruption occurs in a command thread, current remoting task should be canceled. This is what we are doing today when a timeout is set on a command.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 07:46:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 9 Feb 2017 07:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8064) Dependecy Injection not
	working
In-Reply-To: <JIRA.12675715.1486640123000@Atlassian.JIRA>
References: <JIRA.12675715.1486640123000@Atlassian.JIRA>
	<JIRA.12675715.1486640123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675715.1486640123000.87211.1486644360887@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361098#comment-13361098 ] 

Tomaz Cerar commented on WFLY-8064:
-----------------------------------

reproducer?

> Dependecy Injection not working
> -------------------------------
>
>                 Key: WFLY-8064
>                 URL: https://issues.jboss.org/browse/WFLY-8064
>             Project: WildFly
>          Issue Type: Release
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: Windows 2012 R2
>            Reporter: Pradeep Ganapathy
>            Assignee: Stuart Douglas
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>   
>   @Inject
>  private ITestDAO dao;
>   public TestImpl setTestDAO(ITestDAO dao)
>   {
>    this.dao = dao;
>    return this;
>   }
>   @Inject 
> private TestDescription testDescription;
>   public TestImpl setTestDescription(TestDescription testDescription)
>   {
>    this.testDescription = testDescription;
>    return this;
>   }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
>   at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
>   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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>   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:395)
>   ... 35 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 08:02:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 08:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2280) Legacy security realms need
 to reference the client cert mechanism with an underscore
In-Reply-To: <JIRA.12675739.1486645306000@Atlassian.JIRA>
References: <JIRA.12675739.1486645306000@Atlassian.JIRA>
	<JIRA.12675739.1486645306931@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675739.1486645306000.87419.1486645321096@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2280:
----------------------------------------

             Summary: Legacy security realms need to reference the client cert mechanism with an underscore
                 Key: WFCORE-2280
                 URL: https://issues.jboss.org/browse/WFCORE-2280
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 08:25:00 2017
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Thu, 9 Feb 2017 08:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1789) PreparedResponseTestCase
 from wf-core-eap fails intermittently
In-Reply-To: <JIRA.12650020.1473781350000@Atlassian.JIRA>
References: <JIRA.12650020.1473781350000@Atlassian.JIRA>
	<JIRA.12650020.1473781350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650020.1473781350000.87715.1486646700716@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361136#comment-13361136 ] 

Michal Jurc commented on WFCORE-1789:
-------------------------------------

PR submitted: https://github.com/wildfly/wildfly-core/pull/2165

> PreparedResponseTestCase from wf-core-eap fails intermittently
> --------------------------------------------------------------
>
>                 Key: WFCORE-1789
>                 URL: https://issues.jboss.org/browse/WFCORE-1789
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 3.0.0.Alpha7
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha9
>
>         Attachments: firefox.desktop
>
>
> *Description of problem:*
> PreparedResponseTestCase from wf-core-eap fails intermittently with two different stack-trace
> *How reproducible:*
> 2%
> *Actual results: (1. issue)*
> Stack Trace:
> {noformat}
> java.lang.AssertionError: null
> 	at org.junit.Assert.fail(Assert.java:86)
> 	at org.junit.Assert.assertTrue(Assert.java:41)
> 	at org.junit.Assert.assertTrue(Assert.java:52)
> 	at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:113)
> {noformat}
> Standard Output:
> {noformat}
> &amp#27;[0m01:34:22,658 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment slow-stop.jar (runtime-name: slow-stop.jar) in 3025ms
> &amp#27;[0m&amp#27;[0m01:34:22,701 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" stopped in 3071ms
> &amp#27;[0m&amp#27;[0m01:34:22,710 INFO  [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" starting
> &amp#27;[0m&amp#27;[0m01:34:23,243 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> &amp#27;[0m&amp#27;[0m01:34:23,331 INFO  [org.jboss.as.patching] (MSC service thread 1-4) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> &amp#27;[0m&amp#27;[33m01:34:23,361 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-3) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/testsuite/manualmode/target/wildfly-core/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> &amp#27;[0m&amp#27;[33m01:34:23,355 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> &amp#27;[0m&amp#27;[0m01:34:23,367 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "slow-stop.jar" (runtime-name: "slow-stop.jar")
> &amp#27;[0m&amp#27;[33m01:34:23,449 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.controller:main") which may be changed or removed in future versions without notice.
> &amp#27;[0m&amp#27;[33m01:34:23,450 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice.
> &amp#27;[0m&amp#27;[33m01:34:23,452 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.wildfly.extension.request-controller:main") which may be changed or removed in future versions without notice.
> &amp#27;[0m&amp#27;[33m01:34:23,453 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.network:main") which may be changed or removed in future versions without notice.
> &amp#27;[0m&amp#27;[0m01:34:23,479 INFO  [org.wildfly.test.shutdown.SlowStopService] (MSC service thread 1-7) Started with a stop duration of 3000 ms
> &amp#27;[0m&amp#27;[0m01:34:23,528 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "slow-stop.jar" (runtime-name : "slow-stop.jar")
> &amp#27;[0m
> {noformat}
> *Actual results: (2. issue)*
> Stack Trace:
> {noformat}
> java.lang.RuntimeException: java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled
> 	at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267)
> 	at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> 	at org.wildfly.core.testrunner.ManagementClient.executeForResult(ManagementClient.java:234)
> 	at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:102)
> {noformat}
> Standard Output:
> {noformat}
> 11:03:28,015 WARN  [org.jboss.as.protocol.connection] (Remoting "management-client" task-5) WFLYPRT0018: No such request (1) associated with channel Channel ID a37ddd63 (outbound) of Remoting connection 68823cff to /10.16.180.146:9990 of endpoint "management-client" <6645cf9f>
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> Links to jenkins results:
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-Testsuite/view/EAP7-AS-Testsuite-Jobs/job/eap-7x-as-testsuite-test-core/40/RELEASE=7.x.0,jdk=java18_default,label_exp=eap-sustaining&&(RHEL6%7C%7CEAP-RHEL7)/testReport/
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-test-core-rhel/jdk=ibm1.8,label_exp=eap-sustaining&&RHEL6&&x86/49/testReport/
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-test-core-rhel-ipv6/jdk=ibm1.8,label_exp=RHEL7-ipv6/39/testReport/



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 08:27:02 2017
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 9 Feb 2017 08:27:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1418) Binding of List stored in
 Map doesn't work in special case
In-Reply-To: <JIRA.12673228.1485444407000@Atlassian.JIRA>
References: <JIRA.12673228.1485444407000@Atlassian.JIRA>
	<JIRA.12673228.1485444407000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673228.1485444407000.87769.1486646822402@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-1418:
--------------------------------
    Labels: dtable_testday_preparation qe-test-day reported-by-qe  (was: dtable_testday_preparation reported-by-qe)


> Binding of List stored in Map doesn't work in special case
> ----------------------------------------------------------
>
>                 Key: DROOLS-1418
>                 URL: https://issues.jboss.org/browse/DROOLS-1418
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta5
>            Reporter: Jozef Marko
>            Assignee: Mario Fusco
>              Labels: dtable_testday_preparation, qe-test-day, reported-by-qe
>             Fix For: 7.0.0.CR1
>
>         Attachments: reproducer.zip
>
>
> User has possibility to bind a List stored as item of a Map in his rule. However this dosn't work in one special case. For more details see the steps to reproduce.
> This issue was discussed with [~tari_manga] and he also provided the workaround used in reproducer. Thanks.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 09:43:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Thu, 9 Feb 2017 09:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8065) Upgrade IronJacamar to 1.4.2
	from 1.4.1
In-Reply-To: <JIRA.12675772.1486651285000@Atlassian.JIRA>
References: <JIRA.12675772.1486651285000@Atlassian.JIRA>
	<JIRA.12675772.1486651285000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675772.1486651285000.88506.1486651380826@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8753 to WFLY-8065:
----------------------------------------------

           Project: WildFly  (was: JBoss Enterprise Application Platform)
               Key: WFLY-8065  (was: JBEAP-8753)
        Issue Type: Task  (was: Component Upgrade)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: JCA
                        (was: JCA)
    Target Release:   (was: 7.1.0.GA)


> Upgrade IronJacamar to 1.4.2 from 1.4.1
> ---------------------------------------
>
>                 Key: WFLY-8065
>                 URL: https://issues.jboss.org/browse/WFLY-8065
>             Project: WildFly
>          Issue Type: Task
>          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  Thu Feb  9 10:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2281) Add
	wildfly-elytron.tool.jar to bin
In-Reply-To: <JIRA.12675785.1486653265000@Atlassian.JIRA>
References: <JIRA.12675785.1486653265000@Atlassian.JIRA>
	<JIRA.12675785.1486653265870@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675785.1486653265000.88762.1486653300360@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2281:
----------------------------------------

             Summary: Add wildfly-elytron.tool.jar to bin
                 Key: WFCORE-2281
                 URL: https://issues.jboss.org/browse/WFCORE-2281
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 10:20:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 9 Feb 2017 10:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1431) Make property reactivity
 active by default
In-Reply-To: <JIRA.12675788.1486653586000@Atlassian.JIRA>
References: <JIRA.12675788.1486653586000@Atlassian.JIRA>
	<JIRA.12675788.1486653586957@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675788.1486653586000.88824.1486653600445@Atlassian.JIRA>

Mario Fusco created DROOLS-1431:
-----------------------------------

             Summary: 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: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 10:29:01 2017
From: issues at jboss.org (Koen Aers (JIRA))
Date: Thu, 9 Feb 2017 10:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-157) InvocationTargetException
 when opening hibernate structure
In-Reply-To: <JIRA.12648841.1473143688000@Atlassian.JIRA>
References: <JIRA.12648841.1473143688000@Atlassian.JIRA>
	<JIRA.12648841.1473143688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648841.1473143688000.88944.1486654141917@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HIBERNATE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361298#comment-13361298 ] 

Koen Aers commented on HIBERNATE-157:
-------------------------------------

[~amenel] Sorry for the delay on this. I was able to reproduce the problem and found that the root cause is the fact that you are using the EclipseLink persistence provider: 

{{<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>}}

If you remove this line, the error disappears. This is because the Hibernate Tools use the Hibernate runtime to build up the JPA metadata that are shown in the configuration view. Now the Hibernate runtime ignores persistence unit definitions if the specified persistence provider on the unit is not the Hibernate persistence provider. 

In any case, the error message is misleading and should probably be fixed. 

> InvocationTargetException when opening hibernate structure
> ----------------------------------------------------------
>
>                 Key: HIBERNATE-157
>                 URL: https://issues.jboss.org/browse/HIBERNATE-157
>             Project: Hibernate Integration
>          Issue Type: Bug
>         Environment: MacOS10.11.6(El Capitan), Eclipse4.6.0(Neon)
>            Reporter: Yasuyuki Inoue
>            Assignee: Koen Aers
>         Attachments: hibernate-157.zip
>
>
> InvocationTargetException occured when opening existing Hibernate structure.
> !ENTRY org.hibernate.eclipse.console 4 2 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !SUBENTRY 1 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> 	at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> 	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> 	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> 	at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> 	at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> 	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> 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.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> 	... 12 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> 	... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> !STACK 0
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:78)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> 	at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> 	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> 	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> 	at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> 	at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> 	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> 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.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> 	... 12 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> 	... 17 more
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.reflect.InvocationTargetException: <no message>
> !STACK 0
> 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.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> 	at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> 	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> 	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> 	at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> 	at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> 	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> 	... 17 more
> Root exception:
> java.lang.NullPointerException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> 	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.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> 	at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> 	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> 	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> 	at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> 	at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> 	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> !SUBENTRY 2 org.hibernate.eclipse.console 4 150 2016-09-06 15:19:57.154
> !MESSAGE java.lang.NullPointerException: <no message>
> !STACK 0
> java.lang.NullPointerException
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.JPAConfiguration.getMetadata(JPAConfiguration.java:36)
> 	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.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadataFromMethod(MetadataHelper.java:72)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.MetadataHelper.getMetadata(MetadataHelper.java:16)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.getMetadata(ConfigurationFacadeImpl.java:167)
> 	at org.jboss.tools.hibernate.runtime.v_5_1.internal.ConfigurationFacadeImpl.buildMappings(ConfigurationFacadeImpl.java:105)
> 	at org.hibernate.console.ConsoleConfiguration$4.execute(ConsoleConfiguration.java:272)
> 	at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:63)
> 	at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:108)
> 	at org.hibernate.console.ConsoleConfiguration.buildMappings(ConsoleConfiguration.java:270)
> 	at org.hibernate.eclipse.console.workbench.ConsoleConfigurationWorkbenchAdapter.getChildren(ConsoleConfigurationWorkbenchAdapter.java:44)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.getChildren(BasicWorkbenchAdapter.java:98)
> 	at org.hibernate.eclipse.console.workbench.BasicWorkbenchAdapter.fetchDeferredChildren(BasicWorkbenchAdapter.java:104)
> 	at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 10:59:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 9 Feb 2017 10:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8066) Investigate TCP_NIO2 as the
	new default
In-Reply-To: <JIRA.12675804.1486655924000@Atlassian.JIRA>
References: <JIRA.12675804.1486655924000@Atlassian.JIRA>
	<JIRA.12675804.1486655924405@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675804.1486655924000.89142.1486655940555@Atlassian.JIRA>

Radoslav Husar created WFLY-8066:
------------------------------------

             Summary: Investigate TCP_NIO2 as the new default
                 Key: WFLY-8066
                 URL: https://issues.jboss.org/browse/WFLY-8066
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 11:00:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 11:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2282) Get rid of the
 clientRequestExecutor in
 AbstractModelControllerOperationHandlerFactoryService
In-Reply-To: <JIRA.12675805.1486655978000@Atlassian.JIRA>
References: <JIRA.12675805.1486655978000@Atlassian.JIRA>
	<JIRA.12675805.1486655978874@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675805.1486655978000.89175.1486656001873@Atlassian.JIRA>

Brian Stansberry created WFCORE-2282:
----------------------------------------

             Summary: Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService
                 Key: WFCORE-2282
                 URL: https://issues.jboss.org/browse/WFCORE-2282
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
             Fix For: 4.0.0.Beta1


AbstractModelControllerOperationHandlerFactoryService creates a thread pool for handling management requests, with the goal being to limit the number of concurrently executing requests to 4, with tasks for other requests being queued.

There are other ways to do this kind of limitation that do not involve a new thread pool. See Undertow's RequestLimitHandler and related RequestLimit class for the template.

This task is to implement the equivalent in org.jboss.as.controller.remote (not as public API) and then switch the execution to the ServerService Thread Pool (on a server) or the HostControllerService Thread Pool (on an HC). 

It is *not* a request to move execution to the XNIO worker task thread. That should not be done without a very clear discussion.

Part of this task is to account for the thinking that went into a fix for WFCORE-1529. IOW moving work to ServerService Thread Pool / HostControllerService Thread Pool will likely affect the optimum core sizes of those pools. This  AbstractModelControllerOperationHandlerFactoryService.clientRequestExecutor is what is referred to in the PR for WFCORE-1529 in its discussion of "management-handler-thread".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 11:54:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 11:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes
 clearer when using tab completion within CLI
In-Reply-To: <JIRA.12675816.1486659217000@Atlassian.JIRA>
References: <JIRA.12675816.1486659217000@Atlassian.JIRA>
	<JIRA.12675816.1486659217057@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675816.1486659217000.89538.1486659241566@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2283:
----------------------------------------

             Summary: 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
             Fix For: 3.0.0.Alpha25


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 Feb  9 11:55:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 11:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes
 clearer when using tab completion within CLI
In-Reply-To: <JIRA.12675816.1486659217000@Atlassian.JIRA>
References: <JIRA.12675816.1486659217000@Atlassian.JIRA>
	<JIRA.12675816.1486659217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675816.1486659217000.89545.1486659300451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFCORE-2283:
----------------------------------------

    Assignee: Jean-Francois Denise


> 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
>             Fix For: 3.0.0.Alpha25
>
>
> 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 Feb  9 11:58:01 2017
From: issues at jboss.org (Douglas Gardim (JIRA))
Date: Thu, 9 Feb 2017 11:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.89580.1486659481028@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361404#comment-13361404 ] 

Douglas Gardim commented on WFLY-3858:
--------------------------------------

Using 8.2.0.Final here. 
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.

I don't know exactly how to explain this, but I noticed that the security domain actually uses a cache that is named after the security domain's own name. Maybe because it uses exactly the configuration that is defined in the infinispan subsystem it somehow gets updated when it is finally loaded.



> 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: Darran Lofthouse
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> 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<Map, Principal> cm = (CacheableManager<Map, Principal>) 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 Feb  9 12:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 12:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2283) Make 'required' attributes
 clearer when using tab completion within CLI
In-Reply-To: <JIRA.12675816.1486659217000@Atlassian.JIRA>
References: <JIRA.12675816.1486659217000@Atlassian.JIRA>
	<JIRA.12675816.1486659217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675816.1486659217000.89679.1486660680647@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2283:
-------------------------------------
    Fix Version/s:     (was: 3.0.0.Alpha25)


> 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 Feb  9 12:40:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 12:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2270) Capability registry should
 not allow more than one registration point for a
 RuntimeCapabilityRegistration
In-Reply-To: <JIRA.12675177.1486431419000@Atlassian.JIRA>
References: <JIRA.12675177.1486431419000@Atlassian.JIRA>
	<JIRA.12675177.1486431419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675177.1486431419000.89800.1486662000485@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361431#comment-13361431 ] 

Brian Stansberry commented on WFCORE-2270:
------------------------------------------

The work for this involves two PRs, the first of which is now merged:

1) Making whether a RuntimeCapability allows multiple registration points configurable via its Builder, and rejecting cases where multiple registration is attempted when not allowed.

2) Changing the default to not allow multiple registration.

A WildFly Core release will need to be done between 1) and 2) to allow uses in full to take advantage of the config option 1) provides.



> Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2270
>                 URL: https://issues.jboss.org/browse/WFCORE-2270
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. In most cases this is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. And the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, usually the config can only have the same cap in one place.
> There are exceptions to this rule though, so allowing more than one registration point needs to be configurable. Exceptions are basically cases where different resources can register the capability, and the authors of those know about this and have coded up the capability implementations to check for duplication and correctly deal it. For example:
> 1) Both jgroups and and infinispan can provide the same cap, but infinispan knows to check for the presence of jgroups before putting in it's impl. Both are owned by the same author (WildFly clustering team.)
> 2) On an HC, interfaces and paths can be registered in multiple locations that all end up with the same scope. But they don't have to be. The impl understands the precedence rules between those possible locations and the actual capability reflects the correct config.
> I think this latter case is why CapabilityRegistry.registerCapability still allows multiple registration points. But it's a corner case that shouldn't drive all behavior.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 13:19:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 9 Feb 2017 13:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-934) Update
 SecurityDomain.registerWithClassLoader() so that it does not throw an
 IllegalStateException if the security domain that is already registered
 with the specified class loader is the same as this security domain
In-Reply-To: <JIRA.12675830.1486664334000@Atlassian.JIRA>
References: <JIRA.12675830.1486664334000@Atlassian.JIRA>
	<JIRA.12675830.1486664334580@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675830.1486664334000.89960.1486664340566@Atlassian.JIRA>

Farah Juma created ELY-934:
------------------------------

             Summary: Update SecurityDomain.registerWithClassLoader() so that it does not throw an IllegalStateException if the security domain that is already registered with the specified class loader is the same as this security domain
                 Key: ELY-934
                 URL: https://issues.jboss.org/browse/ELY-934
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: API / SPI
            Reporter: Farah Juma
            Assignee: Farah Juma






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 13:36:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 9 Feb 2017 13:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling modes with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303168@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.90094.1486665360084@Atlassian.JIRA>

Edson Tirelli created DROOLS-1432:
-------------------------------------

             Summary: Improve error messages when compiling modes with errors
                 Key: DROOLS-1432
                 URL: https://issues.jboss.org/browse/DROOLS-1432
             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
         Attachments: car_damage_responsibility2.dmn

When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.

At the moment, the attached model fails with a NPE and a message:

{quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 13:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 13:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-935) Change case of aliased in
 beetles.keystore to match vase used in value of CN
In-Reply-To: <JIRA.12675836.1486665957000@Atlassian.JIRA>
References: <JIRA.12675836.1486665957000@Atlassian.JIRA>
	<JIRA.12675836.1486665957714@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675836.1486665957000.90111.1486665960543@Atlassian.JIRA>

Darran Lofthouse created ELY-935:
------------------------------------

             Summary: Change case of aliased in beetles.keystore to match vase used in value of CN
                 Key: ELY-935
                 URL: https://issues.jboss.org/browse/ELY-935
             Project: WildFly Elytron
          Issue Type: Task
          Components: Testsuite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 13:48:00 2017
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 9 Feb 2017 13:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8067) Session scope resolver is not
 properly resolving sessions associated with the request
In-Reply-To: <JIRA.12675837.1486666039000@Atlassian.JIRA>
References: <JIRA.12675837.1486666039000@Atlassian.JIRA>
	<JIRA.12675837.1486666039737@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675837.1486666039000.90119.1486666080472@Atlassian.JIRA>

Pedro Igor created WFLY-8067:
--------------------------------

             Summary: Session scope resolver is not properly resolving sessions associated with the request
                 Key: WFLY-8067
                 URL: https://issues.jboss.org/browse/WFLY-8067
             Project: WildFly
          Issue Type: Bug
          Components: Security, Web (Undertow)
            Reporter: Pedro Igor
            Assignee: Pedro Igor


This issue impacts log in when using any stateful mechanism. It is basically a fix to WFLY-7111.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 14:11:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 14:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-935) Change case of aliased in
 beetles.keystore to match vase used in value of CN
In-Reply-To: <JIRA.12675836.1486665958000@Atlassian.JIRA>
References: <JIRA.12675836.1486665958000@Atlassian.JIRA>
	<JIRA.12675836.1486665958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675836.1486665958000.90197.1486667460386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-935.
----------------------------------
    Resolution: Rejected


Alias case wasn't the problem

> Change case of aliased in beetles.keystore to match vase used in value of CN
> ----------------------------------------------------------------------------
>
>                 Key: ELY-935
>                 URL: https://issues.jboss.org/browse/ELY-935
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Testsuite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 14:43:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 9 Feb 2017 14:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8068) Credential-store attribute
 relative-to doesn't reference path as required
In-Reply-To: <JIRA.12675844.1486669361000@Atlassian.JIRA>
References: <JIRA.12675844.1486669361000@Atlassian.JIRA>
	<JIRA.12675844.1486669361125@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675844.1486669361000.90419.1486669381107@Atlassian.JIRA>

Josef Cacek created WFLY-8068:
---------------------------------

             Summary: Credential-store attribute relative-to doesn't reference path as required
                 Key: WFLY-8068
                 URL: https://issues.jboss.org/browse/WFLY-8068
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse


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 Feb  9 15:13:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Thu, 9 Feb 2017 15:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-6) Migrate API module from existent
	POC repo
In-Reply-To: <JIRA.12675570.1486568716000@Atlassian.JIRA>
References: <JIRA.12675570.1486568716000@Atlassian.JIRA>
	<JIRA.12675570.1486568716000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675570.1486568716000.90525.1486671180206@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro updated AG-6:
---------------------------
    Fix Version/s: 0.0.1


> Migrate API module from existent POC repo
> -----------------------------------------
>
>                 Key: AG-6
>                 URL: https://issues.jboss.org/browse/AG-6
>             Project: Agroal
>          Issue Type: Task
>          Components: api
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.0.1
>
>
> Move the API code currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.
> Rename packages and classes to io.agroal.api.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 15:13:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Thu, 9 Feb 2017 15:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-6) Migrate API module from existent
	POC repo
In-Reply-To: <JIRA.12675570.1486568716000@Atlassian.JIRA>
References: <JIRA.12675570.1486568716000@Atlassian.JIRA>
	<JIRA.12675570.1486568716000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675570.1486568716000.90528.1486671180287@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-6.
----------------------------
    Resolution: Done


> Migrate API module from existent POC repo
> -----------------------------------------
>
>                 Key: AG-6
>                 URL: https://issues.jboss.org/browse/AG-6
>             Project: Agroal
>          Issue Type: Task
>          Components: api
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.0.1
>
>
> Move the API code currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.
> Rename packages and classes to io.agroal.api.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 15:18:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Thu, 9 Feb 2017 15:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-7) Migrate pool module from existent
	POC repo
In-Reply-To: <JIRA.12675847.1486671449000@Atlassian.JIRA>
References: <JIRA.12675847.1486671449000@Atlassian.JIRA>
	<JIRA.12675847.1486671449280@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675847.1486671449000.90538.1486671480211@Atlassian.JIRA>

Luis Barreiro created AG-7:
------------------------------

             Summary: Migrate pool module from existent POC repo
                 Key: AG-7
                 URL: https://issues.jboss.org/browse/AG-7
             Project: Agroal
          Issue Type: Task
          Components: pool
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro


Move the connection pool code (integrated-object-pool) currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.

Rename packages and classes to io.agroal.pool.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:00:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:00: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: <JIRA.12650591.1474136985000@Atlassian.JIRA>
References: <JIRA.12650591.1474136985000@Atlassian.JIRA>
	<JIRA.12650591.1474136985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650591.1474136985000.90723.1486674000141@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1806:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta1)


> 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
>             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<Boolean>, 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  Thu Feb  9 16:02:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1492) The read-attribute result
 for platform mbean properties that throw UnsupportedOperationException
 should be 'undefined'
In-Reply-To: <JIRA.12616095.1461180547000@Atlassian.JIRA>
References: <JIRA.12616095.1461180547000@Atlassian.JIRA>
	<JIRA.12616095.1461180547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616095.1461180547000.90731.1486674120274@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1492:
-------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta1)


> The read-attribute result for platform mbean properties that throw UnsupportedOperationException should be 'undefined'
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1492
>                 URL: https://issues.jboss.org/browse/WFCORE-1492
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>    Affects Versions: 2.1.0.Final
>            Reporter: Brian Stansberry
>
> Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the read-attribute handler will convert the UOE to an OperationFailedException. This JIRA is to change that read-attribute behavior to return undefined as well.
> There was a rationale for the different behavior. Basically, the read-attribute behavior is consistent with what the underlying java.lang.management.XXXMBean does -- it fails. Typically (probably always) there is another boolean getter on the mbean that will tell you if xxx is supported, with the assumption you won't call the unsupported method if not. But for read-resource, we are reading all the attributes, and we guarantee a response value. So we catch the exception and return undefined.
> One minor downside to this is if JMX clients read these attributes, they'll get a null response instead of a failure. But I think that's ok; the MBeanAttributeInfo for these is created by us; these are not the real platform mbeans, they are our wrappers around them really intended for exposure over DMR, not JMX. If a JMX client wants the standard platform mbean semantics, they can access the real underlying platform mbeans.
> This should be done in conjunction with WFCORE-406, which deals with ensuring our management metadata is correct.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.90736.1486674480127@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361517#comment-13361517 ] 

Brian Stansberry commented on WFCORE-972:
-----------------------------------------

Should this be X-Correlation-ID? That shows up as a non-standard header on Wikipedia.

Following the non-standard standard has pros and cons that I don't understand well enough to judge between. So I'm just asking not recommending.

> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-785) Improve capability related
	error messages
In-Reply-To: <JIRA.12576642.1435679852000@Atlassian.JIRA>
References: <JIRA.12576642.1435679852000@Atlassian.JIRA>
	<JIRA.12576642.1435679852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12576642.1435679852000.90739.1486674480231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-785:
------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta1)


> Improve capability related error messages
> -----------------------------------------
>
>                 Key: WFCORE-785
>                 URL: https://issues.jboss.org/browse/WFCORE-785
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:09:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-391) Add management API
 descriptions for alias resources and attributes
In-Reply-To: <JIRA.12528226.1387463281000@Atlassian.JIRA>
References: <JIRA.12528226.1387463281000@Atlassian.JIRA>
	<JIRA.12528226.1387463281000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528226.1387463281000.90741.1486674540119@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-391:
------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta1)


> Add management API descriptions for alias resources and attributes
> ------------------------------------------------------------------
>
>                 Key: WFCORE-391
>                 URL: https://issues.jboss.org/browse/WFCORE-391
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship.
> For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:09:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-391) Add management API
 descriptions for alias resources and attributes
In-Reply-To: <JIRA.12528226.1387463281000@Atlassian.JIRA>
References: <JIRA.12528226.1387463281000@Atlassian.JIRA>
	<JIRA.12528226.1387463281000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12528226.1387463281000.90743.1486674540155@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-391:
------------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> Add management API descriptions for alias resources and attributes
> ------------------------------------------------------------------
>
>                 Key: WFCORE-391
>                 URL: https://issues.jboss.org/browse/WFCORE-391
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship.
> For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:16:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.90762.1486674960255@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361520#comment-13361520 ] 

Brian Stansberry commented on WFCORE-459:
-----------------------------------------

[~jdenise] Very few are. In most cases there's no need for any grouping beyond the resource itself.

Anything on this should be deferred to WF Core 4, as it's late for 3.

Re: the sorting of attributes in the server's read-resource response, I believe they may be sorted by group if there is one, but QE has filed a JBEAP to get rid of that and always sort by name . We'll likely follow through on that. In a higher level view like 'ls', grouping provides benefit, assuming the group is displayed. But for low-level read-resource the group name is not part of the output, and in that case sorting the attributes by group ends up producing what looks like a random sort.

> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta1
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 16:17:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:17: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: <JIRA.12468829.1339696603000@Atlassian.JIRA>
References: <JIRA.12468829.1339696603000@Atlassian.JIRA>
	<JIRA.12468829.1339696603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468829.1339696603000.90773.1486675020440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-389:
------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta1)


> 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
>             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  Thu Feb  9 16:17:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-388) Overall 'server-state' flag
 on the Host Controller
In-Reply-To: <JIRA.12464329.1334681414000@Atlassian.JIRA>
References: <JIRA.12464329.1334681414000@Atlassian.JIRA>
	<JIRA.12464329.1334681414000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464329.1334681414000.90775.1486675020488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-388:
------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta1)


> 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
>
> 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  Thu Feb  9 16:19:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:19:00 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.90785.1486675140318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-396:
------------------------------------
    Issue Type: Enhancement  (was: Feature Request)


> 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.Beta1
>
>
> 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  Thu Feb  9 16:19:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 16:19:00 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.90788.1486675140397@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361522#comment-13361522 ] 

Brian Stansberry commented on WFCORE-396:
-----------------------------------------

I changed this to Enhancement as there's no real user-controllable feature here.

> 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.Beta1
>
>
> 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  Thu Feb  9 18:21:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 9 Feb 2017 18:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2284) Core model test of host.xml
 paths are messed up
In-Reply-To: <JIRA.12675860.1486682444000@Atlassian.JIRA>
References: <JIRA.12675860.1486682444000@Atlassian.JIRA>
	<JIRA.12675860.1486682444377@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675860.1486682444000.90931.1486682460060@Atlassian.JIRA>

Brian Stansberry created WFCORE-2284:
----------------------------------------

             Summary: Core model test of host.xml paths are messed up
                 Key: WFCORE-2284
                 URL: https://issues.jboss.org/browse/WFCORE-2284
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Test Suite
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 3.0.0.Alpha25


While working on https://github.com/wildfly/wildfly-core/pull/2163 Paul Ferraro noticed that HostSpecifiedPathsTestCase was creating a Resource for which there was no corresponding MRR, which his fix then had to handle. Doing that is wrong so I went to clean it up and found that the tests in this package are using incorrect model structures. So I'll clean that up.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 19:25:01 2017
From: issues at jboss.org (Douglas Gardim (JIRA))
Date: Thu, 9 Feb 2017 19:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.91062.1486686301235@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361404#comment-13361404 ] 

Douglas Gardim edited comment on WFLY-3858 at 2/9/17 7:24 PM:
--------------------------------------------------------------

Using 8.2.0.Final here. 
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.




was (Author: dgardim):
Using 8.2.0.Final here. 
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.

I don't know exactly how to explain this, but I noticed that the security domain actually uses a cache that is named after the security domain's own name. Maybe because it uses exactly the configuration that is defined in the infinispan subsystem it somehow gets updated when it is finally loaded.



> 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: Darran Lofthouse
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> 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<Map, Principal> cm = (CacheableManager<Map, Principal>) 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 Feb  9 20:14:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 9 Feb 2017 20:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7965) Coverity static analysis:
 Dereference null return value in ServerAuthenticationContext (Elytron)
In-Reply-To: <JIRA.12672987.1485348828000@Atlassian.JIRA>
References: <JIRA.12672987.1485348828000@Atlassian.JIRA>
	<JIRA.12672987.1485348828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672987.1485348828000.91106.1486689240315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7965:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7965
>                 URL: https://issues.jboss.org/browse/WFLY-7965
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity static-analysis scan found possible dereference null return value in following code
> {code:java|title=ServerAuthenticationContext.java}
> if (log.isTraceEnabled()) {
>                 log.tracef("Authorizing principal %s.", authenticationPrincipal.getName());
>                 log.tracef("Authorizing against the following attributes: %s => %s",
>                         authorizationIdentity.getAttributes().keySet(), authorizationIdentity.getAttributes().values());
>             }
> {code}
> Coverity suppose null value could get here via {{AggregateSecurityRealm.Identity.getAuthorizationIdentity}} calling {{TokenSecurityRealm.TokenRealmIdentity.getAuthorizationIdentity}}
> {code:java|title=TokenRealmIdentity.java}
>         @Override
>         public AuthorizationIdentity getAuthorizationIdentity() throws RealmUnavailableException {
>             if (exists()) {
>                 return new AuthorizationIdentity() {
>                     @Override
>                     public Attributes getAttributes() {
>                         return claims;
>                     }
>                 };
>             }
>             return null;
>         }
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553790&defectInstanceId=2139010&mergedDefectId=1397421&eventId=2139010-2



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 20:19:01 2017
From: issues at jboss.org (Douglas Gardim (JIRA))
Date: Thu, 9 Feb 2017 20:19:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.91130.1486689541186@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361404#comment-13361404 ] 

Douglas Gardim edited comment on WFLY-3858 at 2/9/17 8:18 PM:
--------------------------------------------------------------

Using 8.2.0.Final and got a curious behavior. I created another cache configuration with the same name as the security-domain, so now I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After many redeployments I noticed that most of the times it ends up using the "[security domain name]" configuration. Still not working 100% of the times though.




was (Author: dgardim):
Using 8.2.0.Final here. 
Actually I found another workaround: inside the "security" cache container, create another cache configuration (local-cache in my case) with the same name as the security-domain. So I have 2 cache configurations in my "security" infinispan cache container: "auth-cache" and "[security domain name]". After observing many redeployments I noticed that, when it fails to get the configuration from the "auth-cache", it gets it from the "[security domain name]" configuration instead.



> 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: Darran Lofthouse
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> 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<Map, Principal> cm = (CacheableManager<Map, Principal>) 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 Feb  9 20:20:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 9 Feb 2017 20:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7952) Coverity static analysis:
 Synchronization on java.util.concurrent object in
 ElytronPolicyConfigurationFactory
In-Reply-To: <JIRA.12672827.1485264437000@Atlassian.JIRA>
References: <JIRA.12672827.1485264437000@Atlassian.JIRA>
	<JIRA.12672827.1485264437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672827.1485264437000.91137.1486689600655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7952:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis: Synchronization on java.util.concurrent object in ElytronPolicyConfigurationFactory
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7952
>                 URL: https://issues.jboss.org/browse/WFLY-7952
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            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 Feb  9 21:22:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 21:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of
 CLIENT_CERT authentication for SASL
In-Reply-To: <JIRA.12675877.1486693275000@Atlassian.JIRA>
References: <JIRA.12675877.1486693275000@Atlassian.JIRA>
	<JIRA.12675877.1486693275523@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675877.1486693275000.91179.1486693320277@Atlassian.JIRA>

Darran Lofthouse created ELY-936:
------------------------------------

             Summary: 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.Beta24


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 Feb  9 21:37:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 21:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication
 client has no trust configuration
In-Reply-To: <JIRA.12675878.1486694186000@Atlassian.JIRA>
References: <JIRA.12675878.1486694186000@Atlassian.JIRA>
	<JIRA.12675878.1486694186857@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675878.1486694186000.91193.1486694220188@Atlassian.JIRA>

Darran Lofthouse created ELY-937:
------------------------------------

             Summary: 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.Beta24


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 Feb  9 21:41:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 21:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication
 client should not mandate an input source
In-Reply-To: <JIRA.12675879.1486694444000@Atlassian.JIRA>
References: <JIRA.12675879.1486694444000@Atlassian.JIRA>
	<JIRA.12675879.1486694444191@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675879.1486694444000.91196.1486694460179@Atlassian.JIRA>

Darran Lofthouse created ELY-938:
------------------------------------

             Summary: 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.Beta24


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 Feb  9 21:54:00 2017
From: issues at jboss.org (Jim Ma (JIRA))
Date: Thu, 9 Feb 2017 21:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8069) NPE in
 org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
In-Reply-To: <JIRA.12675880.1486695185000@Atlassian.JIRA>
References: <JIRA.12675880.1486695185000@Atlassian.JIRA>
	<JIRA.12675880.1486695185358@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675880.1486695185000.91198.1486695240108@Atlassian.JIRA>

Jim Ma created WFLY-8069:
----------------------------

             Summary: NPE in org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke
                 Key: WFLY-8069
                 URL: https://issues.jboss.org/browse/WFLY-8069
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
            Reporter: Jim Ma
            Assignee: Jim Ma


The NPE is regularly encountered in a build of the {{invocation_integration}} branch.  Ask me for more details if this problem cannot be reproduced locally.

The log message in {{testsuite/integration/ws/target/jbossas/standalone/log/server.log}} is:
{noformat}
2017-01-30 17:23:57,588 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default-workqueue-1) Application {http://www.jboss.org/jbossws/ws-extensions/wsrm}ReliableService#{http://www.jboss.org/jbossws/ws-e
xtensions/wsrm}writeLogMessage has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault
        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.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
        at org.apache.cxf.ws.addressing.impl.InternalContextUtils$1.run(InternalContextUtils.java:321)
        at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
        at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:109)
        at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:169)
        at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
        ... 17 more
{noformat}

This error is preceded by the following stack trace which might or might not be related:

{noformat}
2017-01-30 17:23:57,460 SEVERE [org.apache.cxf.ws.rm.RMCaptureOutInterceptor] (default task-19) Error persisting message: javax.xml.stream.XMLStreamException: Trying to write END_DOCUMENT when document has no r
oot (ie. trying to output empty document).
        at com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:1584)
        at com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.java:1613)
        at com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1439)
        at com.ctc.wstx.sw.BaseStreamWriter.close(BaseStreamWriter.java:247)
        at org.apache.cxf.staxutils.DelegatingXMLStreamWriter.close(DelegatingXMLStreamWriter.java:35)
        at org.apache.cxf.ws.rm.CapturingXMLWriter.getOutputStream(CapturingXMLWriter.java:397)
        at org.apache.cxf.ws.rm.RMCaptureOutInterceptor$CaptureEnd.handleMessage(RMCaptureOutInterceptor.java:271)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
        at org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:83)
        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:1698)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1698)
        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:210)
        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)

{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 21:56:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 21:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support
 standard KeyManager instances
In-Reply-To: <JIRA.12675881.1486695344000@Atlassian.JIRA>
References: <JIRA.12675881.1486695344000@Atlassian.JIRA>
	<JIRA.12675881.1486695344715@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675881.1486695344000.91208.1486695360170@Atlassian.JIRA>

Darran Lofthouse created ELY-939:
------------------------------------

             Summary: 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.Beta24


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 Feb  9 22:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 22:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-940) key-store-ssl-certificate ->
 key-store-clear-password is wrapping parsing inside the Supplier
In-Reply-To: <JIRA.12675882.1486696659000@Atlassian.JIRA>
References: <JIRA.12675882.1486696659000@Atlassian.JIRA>
	<JIRA.12675882.1486696659917@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675882.1486696659000.91236.1486696680255@Atlassian.JIRA>

Darran Lofthouse created ELY-940:
------------------------------------

             Summary: key-store-ssl-certificate -> key-store-clear-password is wrapping parsing inside the Supplier
                 Key: ELY-940
                 URL: https://issues.jboss.org/browse/ELY-940
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Client
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta24


This means we get errors like this where the parser is accessed after parsing should have finished: -

{{[disconnected /] connect
java.lang.IllegalStateException: Current event not START_ELEMENT
	at com.ctc.wstx.sr.BasicStreamReader.getAttributeCount(BasicStreamReader.java:584)
	at org.wildfly.client.config.BasicXMLStreamReader.getAttributeCount(BasicXMLStreamReader.java:191)
	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
	at org.wildfly.security.auth.client.ElytronXmlParser.parseClearPassword(ElytronXmlParser.java:1864)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$43(ElytronXmlParser.java:1270)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1286)
	at org.wildfly.security.auth.client.ElytronXmlParser$PrivateKeyKeyStoreEntryCredentialFactory.get(ElytronXmlParser.java:2232)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$5(ElytronXmlParser.java:434)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$6(ElytronXmlParser.java:457)
	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:493)
	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:292)
}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb  9 22:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 9 Feb 2017 22:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-940) key-store-ssl-certificate ->
 key-store-clear-password is wrapping parsing inside the Supplier
In-Reply-To: <JIRA.12675882.1486696660000@Atlassian.JIRA>
References: <JIRA.12675882.1486696660000@Atlassian.JIRA>
	<JIRA.12675882.1486696660000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675882.1486696660000.91239.1486696680357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-940:
---------------------------------
    Priority: Critical  (was: Major)


> key-store-ssl-certificate -> key-store-clear-password is wrapping parsing inside the Supplier
> ---------------------------------------------------------------------------------------------
>
>                 Key: ELY-940
>                 URL: https://issues.jboss.org/browse/ELY-940
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta24
>
>
> This means we get errors like this where the parser is accessed after parsing should have finished: -
> {{[disconnected /] connect
> java.lang.IllegalStateException: Current event not START_ELEMENT
> 	at com.ctc.wstx.sr.BasicStreamReader.getAttributeCount(BasicStreamReader.java:584)
> 	at org.wildfly.client.config.BasicXMLStreamReader.getAttributeCount(BasicXMLStreamReader.java:191)
> 	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> 	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseClearPassword(ElytronXmlParser.java:1864)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$43(ElytronXmlParser.java:1270)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1286)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$PrivateKeyKeyStoreEntryCredentialFactory.get(ElytronXmlParser.java:2232)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$5(ElytronXmlParser.java:434)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$6(ElytronXmlParser.java:457)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:493)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:292)
> }}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 02:38:00 2017
From: issues at jboss.org (Heiko Braun (JIRA))
Date: Fri, 10 Feb 2017 02:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.91531.1486712280195@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361609#comment-13361609 ] 

Heiko Braun commented on WFCORE-972:
------------------------------------

I think X-Correlation-ID is fine as well. The rationale behind this request was to support parallel management request execution from the HAL console. [~harald.pehl] Do you want comment on this?

> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 03:18:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 10 Feb 2017 03:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.91686.1486714680373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361629#comment-13361629 ] 

Harald Pehl commented on WFCORE-972:
------------------------------------

That's right, the main driver is to support multiple independent management requests in parallel. The main use case is when we execute r-r-d operations. For complex UIs like Infinispan or ActiveMQ we need to read dozens of resource descriptions upfront.

Right now we partition these r-r-d operations into composite operations with a max of three operations per composite (to reduce the payload). Then we execute and parse the composite operations one after the other. That's necessary to unambiguously map the operation to the result. If we had an unique identifier (correlation id) on the request / response, we would be able to send the operations in parallel and use the correlation id for the mapping.

> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 05:03:00 2017
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Fri, 10 Feb 2017 05:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1369) Property reactive triggers
 stateful working memory corruption on CoachShuttleGathering
In-Reply-To: <JIRA.12663586.1479995518000@Atlassian.JIRA>
References: <JIRA.12663586.1479995518000@Atlassian.JIRA>
	<JIRA.12663586.1479995518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663586.1479995518000.92421.1486720980187@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiri Locker updated DROOLS-1369:
--------------------------------
    Attachment: DroolsReproducerTest.java


> Property reactive triggers stateful working memory corruption on CoachShuttleGathering
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1369
>                 URL: https://issues.jboss.org/browse/DROOLS-1369
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: DroolsReproducerTest.java
>
>
> Not confirmed yet that this is a drools bug, but it probably is :)
> Jiri is isolating.
> To reproduce:
> Use https://github.com/droolsjbpm/optaplanner/pull/234
> and run CloudShuttleGatheringPerformanceTest.
> {code}
> java.lang.IllegalStateException: Impossible VariableListener corruption: the expectedWorkingScore (0hard/-397050soft) is not the workingScore  (-2000000000hard/-397050soft) after all VariableListeners were triggered without changes to the genuine variables.
> But all the shadow variable values are still the same, so this is impossible.
> 	at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertShadowVariablesAreNotStale(AbstractScoreDirector.java:488)
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertShadowVariablesAreNotStale(DefaultSolverScope.java:140)
> 	at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertShadowVariablesAreNotStale(AbstractPhaseScope.java:171)
> 	at org.optaplanner.core.impl.phase.AbstractPhase.predictWorkingStepScore(AbstractPhase.java:169)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.doStep(DefaultLocalSearchPhase.java:102)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:92)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:160)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:65)
> 	at org.optaplanner.examples.coachshuttlegathering.app.CoachShuttleGatheringPerformanceTest.solveDemo01FastAssert(CoachShuttleGatheringPerformanceTest.java:52)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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  Fri Feb 10 05:05:00 2017
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Fri, 10 Feb 2017 05:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1369) Property reactive triggers
 stateful working memory corruption on CoachShuttleGathering
In-Reply-To: <JIRA.12663586.1479995518000@Atlassian.JIRA>
References: <JIRA.12663586.1479995518000@Atlassian.JIRA>
	<JIRA.12663586.1479995518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663586.1479995518000.92427.1486721100393@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361703#comment-13361703 ] 

Jiri Locker commented on DROOLS-1369:
-------------------------------------

Reproducer attached. Source with history can be viewed at https://github.com/yurloc/drools-reproducer/blob/drools1369/src/test/java/org/optaplanner/drools/reproducer/DroolsReproducerTest.java.

> Property reactive triggers stateful working memory corruption on CoachShuttleGathering
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1369
>                 URL: https://issues.jboss.org/browse/DROOLS-1369
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: DroolsReproducerTest.java
>
>
> Not confirmed yet that this is a drools bug, but it probably is :)
> Jiri is isolating.
> To reproduce:
> Use https://github.com/droolsjbpm/optaplanner/pull/234
> and run CloudShuttleGatheringPerformanceTest.
> {code}
> java.lang.IllegalStateException: Impossible VariableListener corruption: the expectedWorkingScore (0hard/-397050soft) is not the workingScore  (-2000000000hard/-397050soft) after all VariableListeners were triggered without changes to the genuine variables.
> But all the shadow variable values are still the same, so this is impossible.
> 	at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertShadowVariablesAreNotStale(AbstractScoreDirector.java:488)
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertShadowVariablesAreNotStale(DefaultSolverScope.java:140)
> 	at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertShadowVariablesAreNotStale(AbstractPhaseScope.java:171)
> 	at org.optaplanner.core.impl.phase.AbstractPhase.predictWorkingStepScore(AbstractPhase.java:169)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.doStep(DefaultLocalSearchPhase.java:102)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:92)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:160)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:65)
> 	at org.optaplanner.examples.coachshuttlegathering.app.CoachShuttleGatheringPerformanceTest.solveDemo01FastAssert(CoachShuttleGatheringPerformanceTest.java:52)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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  Fri Feb 10 05:37:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 10 Feb 2017 05:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1433) DMN Model node with no
 typeRef affected by wrong validation message
In-Reply-To: <JIRA.12675932.1486722999000@Atlassian.JIRA>
References: <JIRA.12675932.1486722999000@Atlassian.JIRA>
	<JIRA.12675932.1486722999288@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675932.1486722999000.92616.1486723020093@Atlassian.JIRA>

Matteo Mortari created DROOLS-1433:
--------------------------------------

             Summary: DMN Model node with no typeRef affected by wrong validation message
                 Key: DROOLS-1433
                 URL: https://issues.jboss.org/browse/DROOLS-1433
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


In the following example:

{code:xml}
  <decision id="d_BureauCallType" name="BureauCallType">
    <variable name="BureauCallType" typeRef="tns:tBureauCallType"/>
    <informationRequirement>
      <requiredDecision href="#d_Pre-bureauRiskCategory"/>
    </informationRequirement>
    <knowledgeRequirement>
      <requiredKnowledge href="#b_BureauCallTypeTable"/>
    </knowledgeRequirement>
    <invocation>
      <literalExpression>
        <text>BureauCallTypeTable</text>
      </literalExpression>
      <binding>
        <parameter id="_65deeb90-626c-4cce-9485-eae9455b2194" name="Pre-bureauRiskCategory"/>
        <literalExpression>
          <text>Pre-bureauRiskCategory</text>
        </literalExpression>
      </binding>
    </invocation>
  </decision>
{code}

the {{invocation}} and {{literalExpression}} node are receiving a wrong validation message for "This element indicates a 'typeRef' which is not in FEEL namespace and not defined with itemDefinition", despite they don't provide any {{typeRef}} at all.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 05:42:00 2017
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Fri, 10 Feb 2017 05:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1369) Property reactive triggers
 stateful working memory corruption on CoachShuttleGathering
In-Reply-To: <JIRA.12663586.1479995518000@Atlassian.JIRA>
References: <JIRA.12663586.1479995518000@Atlassian.JIRA>
	<JIRA.12663586.1479995518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663586.1479995518000.92651.1486723320302@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiri Locker updated DROOLS-1369:
--------------------------------
    Attachment:     (was: DroolsReproducerTest.java)


> Property reactive triggers stateful working memory corruption on CoachShuttleGathering
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1369
>                 URL: https://issues.jboss.org/browse/DROOLS-1369
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: DroolsReproducerTest.java
>
>
> Not confirmed yet that this is a drools bug, but it probably is :)
> Jiri is isolating.
> To reproduce:
> Use https://github.com/droolsjbpm/optaplanner/pull/234
> and run CloudShuttleGatheringPerformanceTest.
> {code}
> java.lang.IllegalStateException: Impossible VariableListener corruption: the expectedWorkingScore (0hard/-397050soft) is not the workingScore  (-2000000000hard/-397050soft) after all VariableListeners were triggered without changes to the genuine variables.
> But all the shadow variable values are still the same, so this is impossible.
> 	at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertShadowVariablesAreNotStale(AbstractScoreDirector.java:488)
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertShadowVariablesAreNotStale(DefaultSolverScope.java:140)
> 	at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertShadowVariablesAreNotStale(AbstractPhaseScope.java:171)
> 	at org.optaplanner.core.impl.phase.AbstractPhase.predictWorkingStepScore(AbstractPhase.java:169)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.doStep(DefaultLocalSearchPhase.java:102)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:92)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:160)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:65)
> 	at org.optaplanner.examples.coachshuttlegathering.app.CoachShuttleGatheringPerformanceTest.solveDemo01FastAssert(CoachShuttleGatheringPerformanceTest.java:52)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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  Fri Feb 10 05:42:00 2017
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Fri, 10 Feb 2017 05:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1369) Property reactive triggers
 stateful working memory corruption on CoachShuttleGathering
In-Reply-To: <JIRA.12663586.1479995518000@Atlassian.JIRA>
References: <JIRA.12663586.1479995518000@Atlassian.JIRA>
	<JIRA.12663586.1479995518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663586.1479995518000.92655.1486723320633@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiri Locker updated DROOLS-1369:
--------------------------------
    Attachment: DroolsReproducerTest.java


> Property reactive triggers stateful working memory corruption on CoachShuttleGathering
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1369
>                 URL: https://issues.jboss.org/browse/DROOLS-1369
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: DroolsReproducerTest.java
>
>
> Not confirmed yet that this is a drools bug, but it probably is :)
> Jiri is isolating.
> To reproduce:
> Use https://github.com/droolsjbpm/optaplanner/pull/234
> and run CloudShuttleGatheringPerformanceTest.
> {code}
> java.lang.IllegalStateException: Impossible VariableListener corruption: the expectedWorkingScore (0hard/-397050soft) is not the workingScore  (-2000000000hard/-397050soft) after all VariableListeners were triggered without changes to the genuine variables.
> But all the shadow variable values are still the same, so this is impossible.
> 	at org.optaplanner.core.impl.score.director.AbstractScoreDirector.assertShadowVariablesAreNotStale(AbstractScoreDirector.java:488)
> 	at org.optaplanner.core.impl.solver.scope.DefaultSolverScope.assertShadowVariablesAreNotStale(DefaultSolverScope.java:140)
> 	at org.optaplanner.core.impl.phase.scope.AbstractPhaseScope.assertShadowVariablesAreNotStale(AbstractPhaseScope.java:171)
> 	at org.optaplanner.core.impl.phase.AbstractPhase.predictWorkingStepScore(AbstractPhase.java:169)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.doStep(DefaultLocalSearchPhase.java:102)
> 	at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:92)
> 	at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87)
> 	at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:160)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:65)
> 	at org.optaplanner.examples.coachshuttlegathering.app.CoachShuttleGatheringPerformanceTest.solveDemo01FastAssert(CoachShuttleGatheringPerformanceTest.java:52)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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  Fri Feb 10 07:25:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 10 Feb 2017 07:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8070) Messaging subsystem passwords
 and credential-reference should be mutually exclusive
In-Reply-To: <JIRA.12675955.1486729498000@Atlassian.JIRA>
References: <JIRA.12675955.1486729498000@Atlassian.JIRA>
	<JIRA.12675955.1486729498212@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675955.1486729498000.93449.1486729501183@Atlassian.JIRA>

Martin Choma created WFLY-8070:
----------------------------------

             Summary: Messaging subsystem passwords and credential-reference should be mutually exclusive
                 Key: WFLY-8070
                 URL: https://issues.jboss.org/browse/WFLY-8070
             Project: WildFly
          Issue Type: Bug
          Components: JMS, Security
            Reporter: Martin Choma
            Assignee: Jeff Mesnil


I don't see any useful use case when I want to configure password attribute in conjuction with credential-reference.
Please mark password attribute and credential-reference in management model as "alternatives".

alternatives ? List of string ? Indicates an exclusive relationship between attributes. If this attribute is defined, the other attributes listed in this descriptor's value should be undefined (even if their required descriptor says true; i.e. the presence of this attribute satisfies the requirement.) Default is undefined; i.e. this does not apply to most attributes.

It applies to:
* {bridge}
  ** Attributes {{password}} and {{credential-reference}} should be mutually exclusive.
* {jms-bridge} 
  ** Attributes {{source-password}} and {{source-credential-reference}} should be mutually exclusive.  
  ** Attributes {{target-password}} and {{target-credential-reference}} should be mutually exclusive.  




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 10 07:26:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 10 Feb 2017 07:26:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8070) Messaging subsystem passwords
 and credential-reference should be mutually exclusive
In-Reply-To: <JIRA.12675955.1486729498000@Atlassian.JIRA>
References: <JIRA.12675955.1486729498000@Atlassian.JIRA>
	<JIRA.12675955.1486729498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675955.1486729498000.93463.1486729561211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8070:
-------------------------------
    Labels: user_experience  (was: )


> Messaging subsystem passwords and credential-reference should be mutually exclusive
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-8070
>                 URL: https://issues.jboss.org/browse/WFLY-8070
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Martin Choma
>            Assignee: Jeff Mesnil
>              Labels: user_experience
>
> I don't see any useful use case when I want to configure password attribute in conjuction with credential-reference.
> Please mark password attribute and credential-reference in management model as "alternatives".
> alternatives ? List of string ? Indicates an exclusive relationship between attributes. If this attribute is defined, the other attributes listed in this descriptor's value should be undefined (even if their required descriptor says true; i.e. the presence of this attribute satisfies the requirement.) Default is undefined; i.e. this does not apply to most attributes.
> It applies to:
> * {bridge}
>   ** Attributes {{password}} and {{credential-reference}} should be mutually exclusive.
> * {jms-bridge} 
>   ** Attributes {{source-password}} and {{source-credential-reference}} should be mutually exclusive.  
>   ** Attributes {{target-password}} and {{target-credential-reference}} should be mutually exclusive.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 10 07:26:02 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 10 Feb 2017 07:26:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5879) Some multinode tests fail
 with security manager
In-Reply-To: <JIRA.12597217.1450441124000@Atlassian.JIRA>
References: <JIRA.12597217.1450441124000@Atlassian.JIRA>
	<JIRA.12597217.1450441124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597217.1450441124000.93489.1486729562022@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361807#comment-13361807 ] 

Ingo Weiss commented on WFLY-5879:
----------------------------------

[~okotek], I just checked these tests on the latest version of 7.x and they passed. Can you double check?

> Some multinode tests fail with security manager
> -----------------------------------------------
>
>                 Key: WFLY-5879
>                 URL: https://issues.jboss.org/browse/WFLY-5879
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Test Suite
>            Reporter: Ondrej Kotek
>            Assignee: Ingo Weiss
>             Fix For: 10.2.0.Final
>
>
> *org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase}}
> fails with:
> {noformat}
> javax.naming.NamingException: Failed to create proxy
> 	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:873)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:222)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:230)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.getStatefulRemote(ClientEjb.java:60)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.testSameTransactionEachCall(ClientEjb.java:77)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	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.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 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: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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb$$$view1.testSameTransactionEachCall(Unknown Source)
> 	at org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall(TransactionInvocationTestCase.java:97)
> {noformat}
> *org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase}}
> fails with:
> {noformat}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-2) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances(DynamicJNDIContextEJBInvocationTestCase.java:116)
> 	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.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:497)
> 	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:497)
> 	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.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:247)
> 	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:223)
> 	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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:92)
> 	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)
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	... 145 more
> 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.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:94)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
> 	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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:302)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 148 more
> Caused by: javax.naming.NamingException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null") [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")]
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:137)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.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:497)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:117)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	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.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	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.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	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 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:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 164 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" 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.ejb.client.EJBClientContext.create(EJBClientContext.java:198)
> 	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:90)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:256)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> 	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:133)
> 	... 223 more
> {noformat}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> fails with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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 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: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.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy62.remoteCall(Unknown Source)
> 	at org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote(RemoteLocalCallProfileTestCase.java:185)
> 	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.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:497)
> 	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:497)
> 	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.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:497)
> 	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.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:247)
> 	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:223)
> 	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 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:497)
> 	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:92)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.marshalling.reflect.SerializableClassRegistry.lookup(SerializableClassRegistry.java:70)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:916)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.SessionOpenResponseHandler$SessionIDResultProducer.getResult(SessionOpenResponseHandler.java:94)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:454)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:227)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:204)
> 	... 226 more
> {code}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> Fail with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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 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: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.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy65.remoteCall(Unknown Source)
> 	at 
> {code}
> *org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode}}
> Fails with:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.16.91.218:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""null"")" [50000-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:160)
> 	at org.h2.message.DbException.convert(DbException.java:283)
> 	at org.h2.message.DbException.toSQLException(DbException.java:256)
> 	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:119)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:90)
> 	at org.h2.Driver.connect(Driver.java:73)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:350)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:285)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1319)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> 	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:482)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:308)
> 	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at 
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 07:32:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 10 Feb 2017 07:32:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8071) Core Bridge,
 Unable to authenticate using credential reference clear text
In-Reply-To: <JIRA.12675957.1486729914000@Atlassian.JIRA>
References: <JIRA.12675957.1486729914000@Atlassian.JIRA>
	<JIRA.12675957.1486729914439@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675957.1486729914000.93587.1486729921310@Atlassian.JIRA>

Martin Choma created WFLY-8071:
----------------------------------

             Summary: Core Bridge, Unable to authenticate using credential reference clear text 
                 Key: WFLY-8071
                 URL: https://issues.jboss.org/browse/WFLY-8071
             Project: WildFly
          Issue Type: Bug
          Components: JMS
            Reporter: Martin Choma
            Assignee: Jeff Mesnil
            Priority: Blocker


When I try to configure core bridge with credential-reference clear-text attribute, bridge can't authenticate to remote destination. When I use attribute password (#testUsernamePasswordCoreBridge) message transfer works OK.

Core bridge configuration:
{code:xml|title=standalone-full-ha.xml}
<bridge name="myBridge" queue-name="jms.queue.InQueue" forwarding-address="jms.queue.OutQueue" ha="true" user="johnOut" static-connectors="bridge-connector">
    <credential-reference clear-text="passwordOut!"/>
</bridge>
{code}

Exception in log:
{code:java|title=server.log}
09:10:30,294 ERROR [org.apache.activemq.artemis.core.server] (default I/O-2) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 07:35:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 10 Feb 2017 07:35:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8072) Core Bridge,
 Unable to authenticate using credential reference alias
In-Reply-To: <JIRA.12675959.1486730092000@Atlassian.JIRA>
References: <JIRA.12675959.1486730092000@Atlassian.JIRA>
	<JIRA.12675959.1486730092777@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675959.1486730092000.93627.1486730101389@Atlassian.JIRA>

Martin Choma created WFLY-8072:
----------------------------------

             Summary: Core Bridge, Unable to authenticate using credential reference alias
                 Key: WFLY-8072
                 URL: https://issues.jboss.org/browse/WFLY-8072
             Project: WildFly
          Issue Type: Bug
          Components: JMS
            Reporter: Martin Choma
            Assignee: Jeff Mesnil
            Priority: Blocker


When I try to configure core bridge with credential-reference alias attribute, bridge can't authenticate to remote destination. When I use attribute password (#testUsernamePasswordCoreBridge) message transfer works OK.

Core bridge configuration:
{code:xml|title=standalone-full-ha.xml}
<credential-stores>
    <credential-store name="bridge-cs001" relative-to="jboss.server.data.dir">
        <uri>cr-store://test/bridge-cs001.jceks</uri>
        <credential-reference clear-text="pass123"/>
    </credential-store>
</credential-stores>

<bridge name="myBridge" queue-name="jms.queue.InQueue" forwarding-address="jms.queue.OutQueue" ha="true" user="johnOut" static-connectors="bridge-connector">
    <credential-reference store="bridge-cs001" alias="john_out_alias"/>
</bridge>
{code}

Exception in log:
{code:java|title=server.log}
10:38:17,947 ERROR [org.apache.activemq.artemis.core.server] (default I/O-11) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.3.Final-redhat-1.jar:3.4.3.Final-redhat-1]
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 07:45:00 2017
From: issues at jboss.org (huanghwh (JIRA))
Date: Fri, 10 Feb 2017 07:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to
	connect
In-Reply-To: <JIRA.12668415.1482247594000@Atlassian.JIRA>
References: <JIRA.12668415.1482247594000@Atlassian.JIRA>
	<JIRA.12668415.1482247594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668415.1482247594000.93783.1486730700336@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361826#comment-13361826 ] 

huanghwh commented on WFLY-7823:
--------------------------------

I upgrade *proton-j to 0.15.0 and netty-all to 4.1.5.-Final*
Simple amqp remote client run successfully.
btw proton-jms seems not need.


> 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 <WFLY_HOME>/modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. <module name="io.netty"/>).
> 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 <WFLY_HOME>/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  Fri Feb 10 07:49:01 2017
From: issues at jboss.org (huanghwh (JIRA))
Date: Fri, 10 Feb 2017 07:49:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to
	connect
In-Reply-To: <JIRA.12668415.1482247594000@Atlassian.JIRA>
References: <JIRA.12668415.1482247594000@Atlassian.JIRA>
	<JIRA.12668415.1482247594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668415.1482247594000.93860.1486730941614@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361826#comment-13361826 ] 

huanghwh edited comment on WFLY-7823 at 2/10/17 7:49 AM:
---------------------------------------------------------

I upgrade *proton-j to 0.15.0 and netty-all to 4.1.5.-Final*
Simple amqp remote client run successfully.
btw:
1. <module name="io.netty"/> is need in "artemis/protocol/amqp/main/module.xml"
2. proton-jms seems not need.




was (Author: huanghwh):
I upgrade *proton-j to 0.15.0 and netty-all to 4.1.5.-Final*
Simple amqp remote client run successfully.
btw proton-jms seems not need.


> 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 <WFLY_HOME>/modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. <module name="io.netty"/>).
> 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 <WFLY_HOME>/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  Fri Feb 10 07:51:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 10 Feb 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1434) Refactor core API and FEEL
 API into kie-dmn-api module
In-Reply-To: <JIRA.12675962.1486731041000@Atlassian.JIRA>
References: <JIRA.12675962.1486731041000@Atlassian.JIRA>
	<JIRA.12675962.1486731041194@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675962.1486731041000.93906.1486731060177@Atlassian.JIRA>

Matteo Mortari created DROOLS-1434:
--------------------------------------

             Summary: Refactor core API and FEEL API into kie-dmn-api module
                 Key: DROOLS-1434
                 URL: https://issues.jboss.org/browse/DROOLS-1434
             Project: Drools
          Issue Type: Enhancement
          Components: dmn engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 08:33:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Fri, 10 Feb 2017 08:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-425) drools 6.0.1 workbench
 cannot work on tomcat7.0
In-Reply-To: <JIRA.12531688.1392090825000@Atlassian.JIRA>
References: <JIRA.12531688.1392090825000@Atlassian.JIRA>
	<JIRA.12531688.1392090825000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12531688.1392090825000.94430.1486733580450@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? closed DROOLS-425.
------------------------------
    Resolution: Out of Date


> drools 6.0.1 workbench cannot work on tomcat7.0
> -----------------------------------------------
>
>                 Key: DROOLS-425
>                 URL: https://issues.jboss.org/browse/DROOLS-425
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.0.1.Final
>         Environment: windows8, 64bits,  jdk 6.0
>            Reporter: lory hou
>            Assignee: Mark Proctor
>
> I download kie-drools-wb-distribution-6.0.1.Final, and unzip it, copy kie-drools-wb-distribution-wars-6.0.1.Final-tomcat7.0.war into tomcat7.0. After restarting tomcat, there is only one error logged in catalina.out and cause drools workbench cannot start correctly.
> Error listenerStart 
> Context [/kie-wb] startup failed due to previous errors
> The whole error log is following:
> ??: Deploying web application directory D:\green\tomcat\webapps\kie-wb 2014-2-11 10:22:36 org.apache.catalina.core.StandardContext startInternal 
> ??: Error listenerStart 2014-2-11 10:22:36 org.apache.catalina.core.StandardContext startInternal 
> ??: Context [/kie-wb] startup failed due to previous errors



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 10 08:35:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 10 Feb 2017 08:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2285) Error message of reload
 operation in embedded host is wrong
In-Reply-To: <JIRA.12675969.1486733666000@Atlassian.JIRA>
References: <JIRA.12675969.1486733666000@Atlassian.JIRA>
	<JIRA.12675969.1486733666948@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675969.1486733666000.94449.1486733700323@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2285:
--------------------------------------------

             Summary: Error message of reload operation in embedded host is wrong
                 Key: WFCORE-2285
                 URL: https://issues.jboss.org/browse/WFCORE-2285
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 08:42:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 08:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8073) Failed to purge registry of
 old registry entries
In-Reply-To: <JIRA.12675971.1486734043000@Atlassian.JIRA>
References: <JIRA.12675971.1486734043000@Atlassian.JIRA>
	<JIRA.12675971.1486734043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675971.1486734043000.94530.1486734120310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-8771 to WFLY-8073:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8073  (was: JBEAP-8771)
             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.DR8)


> Failed to purge registry of old registry entries
> ------------------------------------------------
>
>                 Key: WFLY-8073
>                 URL: https://issues.jboss.org/browse/WFLY-8073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> We saw this warning in failover tests on *server*. Occurs few second after new cluster view was received.
> Every failover scenario is affected (approx. 4 occurences each).
> Server log stacktrace:
> {code}
> 15:29:05,207 WARN  [org.wildfly.clustering.server] (transport-thread--p14-t5) WFLYCLSV0010: Failed to purge ejb/client-mappings registry of old registry entries for: [perf19]: org.infinispan.commons.CacheException: javax.transaction.HeuristicMixedException
> [JBossINF] 	at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:102)
> [JBossINF] 	at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:184)
> [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:498)
> [JBossINF] 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:297)
> [JBossINF] 	at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:20)
> [JBossINF] 	at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:320)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1237)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1195)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1160)
> [JBossINF] 	at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:594)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:195)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:46)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:113)
> [JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:328)
> [JBossINF] 	at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:253)
> [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:172)
> [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 org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> [JBossINF] 	at java.lang.Thread.run(Thread.java:745)
> [JBossINF] Caused by: javax.transaction.HeuristicMixedException
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:439)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:448)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:321)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:108)
> [JBossINF] 	at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> [JBossINF] 	... 25 more
> [JBossINF] Caused by: javax.transaction.xa.XAException
> [JBossINF] 	at org.infinispan.transaction.impl.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:207)
> [JBossINF] 	at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:159)
> [JBossINF] 	at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:114)
> [JBossINF] 	at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:401)
> [JBossINF] 	... 29 more
> [JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 13
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferLockImpl.reportErrorAfterWait(StateTransferLockImpl.java:159)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:98)
> [JBossINF] 	at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:249)
> [JBossINF] 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:87)
> [JBossINF] 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [JBossINF] 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> [JBossINF] 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [JBossINF] 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [JBossINF] 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> [JBossINF] 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> [JBossINF] 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [JBossINF] 	at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:157)
> [JBossINF] 	... 31 more
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failover-ejb-ejbremote-jvmkill-dist-async/2/console-perf20/



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 08:51:01 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 10 Feb 2017 08:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8074) JCA1.7
 MessageEndpointFactory.getActivationName() returns null
In-Reply-To: <JIRA.12675978.1486734612000@Atlassian.JIRA>
References: <JIRA.12675978.1486734612000@Atlassian.JIRA>
	<JIRA.12675978.1486734612000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675978.1486734612000.94662.1486734661117@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8773 to WFLY-8074:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8074  (was: JBEAP-8773)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                           (was: JCA)
    Affects Version/s:     (was: 7.0.4.GA)


> JCA1.7 MessageEndpointFactory.getActivationName() returns null
> --------------------------------------------------------------
>
>                 Key: WFLY-8074
>                 URL: https://issues.jboss.org/browse/WFLY-8074
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> As per JCA 1.7 spec. and JavaDoc, it should return "a new String instance representing the unique name of the message endpoint deployment". However, it returns null.
> JCA 1.7 and was implemented in IronJacamar via https://issues.jboss.org/browse/JBJCA-983 and is described in http://www.ironjacamar.org/doc/api/spec/1.7/javax/resource/spi/endpoint/MessageEndpointFactory.html
> Based on latest code at https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java
> * there is a getActivationName() method but no setActivationName(Sting xyz) method
> * Private variable activationName.defined but never set
> * not set in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/inflow/JBossMessageEndpointFactory.java either



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 09:27:03 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 10 Feb 2017 09:27:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8075) datasources subsystem should
 not depend on legacy security subsystem
In-Reply-To: <JIRA.12675984.1486736769000@Atlassian.JIRA>
References: <JIRA.12675984.1486736769000@Atlassian.JIRA>
	<JIRA.12675984.1486736769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675984.1486736769000.95137.1486736823957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8774 to WFLY-8075:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8075  (was: JBEAP-8774)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                           (was: JCA)
    Affects Version/s:     (was: 7.1.0.DR11)


> datasources subsystem should not depend on legacy security subsystem
> --------------------------------------------------------------------
>
>                 Key: WFLY-8075
>                 URL: https://issues.jboss.org/browse/WFLY-8075
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Critical
>
> After removing the legacy {{security}} subsystem and booting the server, you see
> {noformat}
> 11:31:07,203 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "ExampleDS")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.security.subject-factory",
>         "jboss.security.simple-security-manager"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.data-source.ExampleDS is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"]
> }
> 11:31:07,207 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "ExampleDS")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.security.subject-factory",
>         "jboss.security.simple-security-manager",
>         "jboss.security.subject-factory",
>         "jboss.security.simple-security-manager"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "org.wildfly.data-source.ExampleDS is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]",
>         "org.wildfly.data-source.ExampleDS is missing [jboss.security.simple-security-manager, jboss.security.subject-factory]"
>     ]
> }
> {noformat}
> Which means that datasources 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  Fri Feb 10 09:37:01 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 09:37:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6357) WARN ISPN000112: exception
 while committing: javax.transaction.xa.XAException due to replication
 timeout
In-Reply-To: <JIRA.12610250.1457945378000@Atlassian.JIRA>
References: <JIRA.12610250.1457945378000@Atlassian.JIRA>
	<JIRA.12610250.1457945378000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610250.1457945378000.95248.1486737421354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-6357:
-------------------------------
    Priority: Critical  (was: Major)


> WARN ISPN000112: exception while committing: javax.transaction.xa.XAException due to replication timeout
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6357
>                 URL: https://issues.jboss.org/browse/WFLY-6357
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Final
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> This is a separate issue originally logged as part of JBEAP-794 (#4 in this [comment|https://issues.jboss.org/browse/JBEAP-794?focusedCommentId=13170628&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13170628]). 
> Seen in ejb-remote, ejb-ejbservlet and http-session scenarios with *REPL* cache and *SYNC* replication.
> TimeoutException occured after perf18 (or any other node) rejoined a cluster (after graceful shutdown, jvmkill or undeploy - it doesn't matter), but it does not seem to affect client:
> {code}
> [JBossINF] [0m[33m03:23:38,462 WARN  [org.infinispan.transaction.tm.DummyTransaction] (default task-24) ISPN000112: exception while committing: javax.transaction.xa.XAException
> [JBossINF]     at org.infinispan.transaction.impl.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:213)
> [JBossINF]     at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:159)
> [JBossINF]     at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:114)
> [JBossINF]     at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:401)
> [JBossINF]     at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:448)
> [JBossINF]     at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:321)
> [JBossINF]     at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:108)
> [JBossINF]     at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:71)
> [JBossINF]     at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:76)
> [JBossINF]     at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
> [JBossINF]     at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:563)
> [JBossINF]     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> [JBossINF]     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> [JBossINF]     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF]     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> [JBossINF]     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [JBossINF]     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> [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] Caused by: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF]     at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:765)
> [JBossINF]     at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$175(JGroupsTransport.java:612)
> [JBossINF]     at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF]     at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF]     at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF]     at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF]     at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> [JBossINF]     at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> [JBossINF]     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF]     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF]     at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF]     ... 3 more
> {code}
> Also, JBEAP-3779 an JBEAP-3780 (and partially also JBEAP-3782) accompany this issue, see [occurrences report|http://download.eng.brq.redhat.com/scratch/mvinkler/reports/occurrences/ER6/timeoutExceptions.html] 
> Server link:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-session-shutdown-repl-sync/18/console-perf18/ 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 10:23:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 10 Feb 2017 10:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-751) Coverity static analysis:
 Explicit null dereferenced in LdapKeyStore (Elytron)
In-Reply-To: <JIRA.12661417.1479131134000@Atlassian.JIRA>
References: <JIRA.12661417.1479131134000@Atlassian.JIRA>
	<JIRA.12661417.1479131134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661417.1479131134000.95832.1486740180696@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reopened ELY-751:
-------------------------------


JBEAP-7246 (reopen):
Please replace type "LdapRealm" -> "LdapKeyStore".
LdapKeyStore is not key store of type LdapRealm.


> Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron)
> ------------------------------------------------------------------------------
>
>                 Key: ELY-751
>                 URL: https://issues.jboss.org/browse/ELY-751
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta17
>
>
> Coverity static-analysis scan found possible use of null object in  {{LdapKeyStore}} constructor.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760194&defectInstanceId=1541374&mergedDefectId=1369294
> The {{LdapKeyStore.Builder.build()}} method constructs the {{LdapKeyStore}} instance this way:
> {code}
>   return new LdapKeyStore(spi, null, null);
> {code}
> and the constructor just calls parent ctor:
> {code}
>     protected LdapKeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type) {
>         super(keyStoreSpi, provider, type);
>     }
> {code}
> And it fails with NPE if debug for {{KeyStore}} is enabled as the constructor contains:
> {code}
>         if (!skipDebug && pdebug != null) {
>             pdebug.println("KeyStore." + type.toUpperCase() + " type from: " +
>                 this.provider.getName());
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 10:25:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 10 Feb 2017 10:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-751) Coverity static analysis:
 Explicit null dereferenced in LdapKeyStore (Elytron)
In-Reply-To: <JIRA.12661417.1479131134000@Atlassian.JIRA>
References: <JIRA.12661417.1479131134000@Atlassian.JIRA>
	<JIRA.12661417.1479131134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661417.1479131134000.95868.1486740300581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-751:
------------------------------
    Fix Version/s:     (was: 1.1.0.Beta17)


> Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron)
> ------------------------------------------------------------------------------
>
>                 Key: ELY-751
>                 URL: https://issues.jboss.org/browse/ELY-751
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>
> Coverity static-analysis scan found possible use of null object in  {{LdapKeyStore}} constructor.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760194&defectInstanceId=1541374&mergedDefectId=1369294
> The {{LdapKeyStore.Builder.build()}} method constructs the {{LdapKeyStore}} instance this way:
> {code}
>   return new LdapKeyStore(spi, null, null);
> {code}
> and the constructor just calls parent ctor:
> {code}
>     protected LdapKeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type) {
>         super(keyStoreSpi, provider, type);
>     }
> {code}
> And it fails with NPE if debug for {{KeyStore}} is enabled as the constructor contains:
> {code}
>         if (!skipDebug && pdebug != null) {
>             pdebug.println("KeyStore." + type.toUpperCase() + " type from: " +
>                 this.provider.getName());
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 10:26:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 10 Feb 2017 10:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-751) Coverity static analysis:
 Explicit null dereferenced in LdapKeyStore (Elytron)
In-Reply-To: <JIRA.12661417.1479131134000@Atlassian.JIRA>
References: <JIRA.12661417.1479131134000@Atlassian.JIRA>
	<JIRA.12661417.1479131134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661417.1479131134000.95875.1486740360554@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13361975#comment-13361975 ] 

Ilia Vassilev commented on ELY-751:
-----------------------------------

Replaced "LdapRealm" -> "LdapKeyStore" with PR [1].

[1] https://github.com/wildfly-security/wildfly-elytron/pull/669

> Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron)
> ------------------------------------------------------------------------------
>
>                 Key: ELY-751
>                 URL: https://issues.jboss.org/browse/ELY-751
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>
> Coverity static-analysis scan found possible use of null object in  {{LdapKeyStore}} constructor.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760194&defectInstanceId=1541374&mergedDefectId=1369294
> The {{LdapKeyStore.Builder.build()}} method constructs the {{LdapKeyStore}} instance this way:
> {code}
>   return new LdapKeyStore(spi, null, null);
> {code}
> and the constructor just calls parent ctor:
> {code}
>     protected LdapKeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type) {
>         super(keyStoreSpi, provider, type);
>     }
> {code}
> And it fails with NPE if debug for {{KeyStore}} is enabled as the constructor contains:
> {code}
>         if (!skipDebug && pdebug != null) {
>             pdebug.println("KeyStore." + type.toUpperCase() + " type from: " +
>                 this.provider.getName());
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 10:38:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 10 Feb 2017 10:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2254)
 InterdependentDeploymentTestCase fails with security manager
In-Reply-To: <JIRA.12674107.1485947036000@Atlassian.JIRA>
References: <JIRA.12674107.1485947036000@Atlassian.JIRA>
	<JIRA.12674107.1485947036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674107.1485947036000.95999.1486741080234@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFCORE-2254:
----------------------------------

    Assignee: Ingo Weiss


> 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
>
> *org.jboss.as.test.manualmode.deployment.InterdependentDeploymentTestCase#test*
> {{cd testsuite/manualmode/}}
> {{mvn test -DtestLogToFile=false -Dtest=InterdependentDeploymentTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service ServiceActivatorDeployment.c: org.jboss.msc.service.StartException in service ServiceActivatorDeployment.c: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 	at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "interrelated-c.jar" "write")" in code source "(vfs:/content/interrelated-a.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.interrelated-a.jar" from Service Module Loader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.System.setProperty(System.java:792)
> 	at org.jboss.as.test.deployment.trivial.ServiceActivatorDeployment.start(ServiceActivatorDeployment.java:91)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 	... 4 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 10:53:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Feb 2017 10:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-941) Allow provider name to be null
 in SSLContextBuilder
In-Reply-To: <JIRA.12676008.1486741943000@Atlassian.JIRA>
References: <JIRA.12676008.1486741943000@Atlassian.JIRA>
	<JIRA.12676008.1486741943621@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676008.1486741943000.96137.1486741980454@Atlassian.JIRA>

Darran Lofthouse created ELY-941:
------------------------------------

             Summary: Allow provider name to be null in SSLContextBuilder
                 Key: ELY-941
                 URL: https://issues.jboss.org/browse/ELY-941
             Project: WildFly Elytron
          Issue Type: Task
          Components: SSL
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta24


The utility searching for the provider takes 'null' to mean any provider allowed so a 'null' value should be allowed.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 11:51:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 10 Feb 2017 11:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8076) datasources and
 resource-adapter subsystems: credential-reference and password should be
 mutually exclusive
In-Reply-To: <JIRA.12676022.1486745374000@Atlassian.JIRA>
References: <JIRA.12676022.1486745374000@Atlassian.JIRA>
	<JIRA.12676022.1486745374000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676022.1486745374000.96487.1486745460704@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8776 to WFLY-8076:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8076  (was: JBEAP-8776)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                       Security
                           (was: JCA)
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR11)


> datasources and resource-adapter subsystems: credential-reference and password should be mutually exclusive
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8076
>                 URL: https://issues.jboss.org/browse/WFLY-8076
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, Security
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> credential-reference and password should be mutually exclusive, they should have alternatives set
> {noformat}
>             "password" => {
>                 "type" => STRING,
>                 "description" => "Specifies the password used when creating a new connection",
>                 "expressions-allowed" => true,
>                 "required" => false,
>                 "nillable" => true,
>                 "requires" => ["user-name"],
>                 "min-length" => 1L,
>                 "max-length" => 2147483647L,
>                 "access-constraints" => {"sensitive" => {
>                     "credential" => {"type" => "core"},
>                     "data-source-security" => {"type" => "datasources"}
>                 }},
>                 "access-type" => "read-write",
>                 "storage" => "configuration",
>                 "restart-required" => "no-services"
>             },
>           "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"
>             }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 12:12:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Fri, 10 Feb 2017 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8077) datasource subsystem -
 credential-reference doesn't work
In-Reply-To: <JIRA.12676031.1486746634000@Atlassian.JIRA>
References: <JIRA.12676031.1486746634000@Atlassian.JIRA>
	<JIRA.12676031.1486746634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676031.1486746634000.97048.1486746720416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8777 to WFLY-8077:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8077  (was: JBEAP-8777)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                       Security
                           (was: JCA)
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR11)


> datasource subsystem - credential-reference doesn't work
> --------------------------------------------------------
>
>                 Key: WFLY-8077
>                 URL: https://issues.jboss.org/browse/WFLY-8077
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, Security
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Blocker
>
> There are more issues:
> # credential reference is always (not)resolved to _undefined_. It works with ExampleDS and H2 because it accepts any password.
> I tried to fix it in [f512ce274c8837f642e0a7a949018acdfd2a017e|https://github.com/simkam/wildfly/commit/f512ce274c8837f642e0a7a949018acdfd2a017e]
> # when #1 is fixed, {{<credential-reference clear-text="pass" />}} works, but {{<credential-reference store="store" alias="alias" />}} doesn't. 
> {noformat}
> 18:00:07,970 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "datasources"),
>     ("data-source" => "StoreAliasCredentialReferenceDatasource")
> ]): java.lang.IllegalArgumentException: value is null
>         at org.jboss.dmr.ModelNode.<init>(ModelNode.java:167)
>         at org.jboss.as.controller.OperationFailedException.<init>(OperationFailedException.java:59)
>         at org.jboss.as.controller.OperationFailedException.<init>(OperationFailedException.java:98)
>         at org.jboss.as.connector.subsystems.datasources.DataSourceModelNodeUtil.from(DataSourceModelNodeUtil.java:192)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.secondRuntimeStep(AbstractDataSourceAdd.java:328)
>         at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd$1.execute(AbstractDataSourceAdd.java:137)
>         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: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}
> https://github.com/simkam/wildfly/commits/credential-reference contains tests and fix for #1



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 12:54:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 10 Feb 2017 12:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-28) hawkular-qe-manual
In-Reply-To: <JIRA.12674839.1486137657000@Atlassian.JIRA>
References: <JIRA.12674839.1486137657000@Atlassian.JIRA>
	<JIRA.12674839.1486137657000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674839.1486137657000.97198.1486749240699@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362080#comment-13362080 ] 

Matt Mahoney commented on HAWKULARQE-28:
----------------------------------------

[link title|https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10028]
[link title|https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10027]
[link title|https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10029]
[link title|https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10030]


> hawkular-qe-manual
> ------------------
>
>                 Key: HAWKULARQE-28
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-28
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Matt Mahoney
>            Assignee: mfoley user
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 12:55:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 10 Feb 2017 12:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-28) hawkular-qe-manual
In-Reply-To: <JIRA.12674839.1486137657000@Atlassian.JIRA>
References: <JIRA.12674839.1486137657000@Atlassian.JIRA>
	<JIRA.12674839.1486137657000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674839.1486137657000.97207.1486749300458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Mahoney updated HAWKULARQE-28:
-----------------------------------
    Description: 

https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10028
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10027
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10029
https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10030


> hawkular-qe-manual
> ------------------
>
>                 Key: HAWKULARQE-28
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-28
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Matt Mahoney
>            Assignee: mfoley user
>
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10028
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10027
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10029
> https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10030



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 13:28:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 10 Feb 2017 13:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8078) Add ability to use an XA data
 source from many distributed JTA nodes
In-Reply-To: <JIRA.12676044.1486751228000@Atlassian.JIRA>
References: <JIRA.12676044.1486751228000@Atlassian.JIRA>
	<JIRA.12676044.1486751228492@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676044.1486751228000.97318.1486751280173@Atlassian.JIRA>

David Lloyd created WFLY-8078:
---------------------------------

             Summary: Add ability to use an XA data source from many distributed JTA nodes
                 Key: WFLY-8078
                 URL: https://issues.jboss.org/browse/WFLY-8078
             Project: WildFly
          Issue Type: Enhancement
          Components: Transactions
            Reporter: David Lloyd
            Priority: Optional


*Note* that this issue is not scheduled and is low priority.  To start, it is just a point to conjecture implementation possibilities.

Provide the ability for a data source (or other XA resource) to be utilized from multiple nodes in the distributed JTA node graph.  This may allow multiple nodes to operate within the same transaction on these resources.

The requirements are:

# The XA resource in question must support multiple connections
# A way is needed to ensure that all nodes are using the same branch qualifier for the given resource
# A way is needed to decide which node is the "master" for the given resource

Requirement #2 is necessary because otherwise the node in question may not be able to correlate the incoming connections.

Requirement #3 is necessary to avoid multiple nodes preparing the transaction.  The usual JTA technique of using isSameRM does not work because every node has their own partial view of the complete set of XA resources involved in the distributed transaction.

Some possible ideas (not complete and not mutually inclusive or exclusive):
* Allow hard-coding a branch qualifier for a resource in some way, so all nodes always use the same branch ID for a given resource
* Somehow communicate all resource enlistments to the root node during prepare so the root node can determine which ones need to be prepared via isSameRM checks (this would require serializing the XA resources, which in turn requires (more or less) all nodes to have all classes for all resources present and loadable)
* Revisit idea of hierarchical branch qualifiers
* ...(add your idea here!)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 14:03:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Feb 2017 14:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-37) Audit Logging Integration
In-Reply-To: <JIRA.12548096.1406826316000@Atlassian.JIRA>
References: <JIRA.12548096.1406826316000@Atlassian.JIRA>
	<JIRA.12548096.1406826316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548096.1406826316000.97479.1486753380438@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-37:
--------------------------------
    Fix Version/s: 1.1.0.Beta24
                       (was: 1.1.0.CR1)


> Audit Logging Integration
> -------------------------
>
>                 Key: ELY-37
>                 URL: https://issues.jboss.org/browse/ELY-37
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Audit
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta24
>
>
> Implement into Elytron samething like:
> https://github.com/picketbox/picketbox/tree/master/security-spi/spi/src/main/java/org/jboss/security/audit
> or
> https://github.com/wildfly/wildfly-core/tree/master/controller/src/main/java/org/jboss/as/controller/audit
> or
> https://github.com/kabir/tamper-detecting-audit-log
> UPDATE:
> By discussion should be based on currently not implemented processing of **security events** - depends on it from now.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 14:03:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Feb 2017 14:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-37) Audit Logging Integration
In-Reply-To: <JIRA.12548096.1406826316000@Atlassian.JIRA>
References: <JIRA.12548096.1406826316000@Atlassian.JIRA>
	<JIRA.12548096.1406826316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548096.1406826316000.97474.1486753380335@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-37:
-----------------------------------

    Assignee: Darran Lofthouse  (was: Jan Kalina)


> Audit Logging Integration
> -------------------------
>
>                 Key: ELY-37
>                 URL: https://issues.jboss.org/browse/ELY-37
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Audit
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta24
>
>
> Implement into Elytron samething like:
> https://github.com/picketbox/picketbox/tree/master/security-spi/spi/src/main/java/org/jboss/security/audit
> or
> https://github.com/wildfly/wildfly-core/tree/master/controller/src/main/java/org/jboss/as/controller/audit
> or
> https://github.com/kabir/tamper-detecting-audit-log
> UPDATE:
> By discussion should be based on currently not implemented processing of **security events** - depends on it from now.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 14:03:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Feb 2017 14:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-37) Audit Logging Integration
In-Reply-To: <JIRA.12548096.1406826316000@Atlassian.JIRA>
References: <JIRA.12548096.1406826316000@Atlassian.JIRA>
	<JIRA.12548096.1406826316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548096.1406826316000.97484.1486753380753@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-37:
--------------------------------
    Priority: Critical  (was: Major)


> Audit Logging Integration
> -------------------------
>
>                 Key: ELY-37
>                 URL: https://issues.jboss.org/browse/ELY-37
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Audit
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta24
>
>
> Implement into Elytron samething like:
> https://github.com/picketbox/picketbox/tree/master/security-spi/spi/src/main/java/org/jboss/security/audit
> or
> https://github.com/wildfly/wildfly-core/tree/master/controller/src/main/java/org/jboss/as/controller/audit
> or
> https://github.com/kabir/tamper-detecting-audit-log
> UPDATE:
> By discussion should be based on currently not implemented processing of **security events** - depends on it from now.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 14:06:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 10 Feb 2017 14:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra and Metrics
 Serice Restarts During Initialization
In-Reply-To: <JIRA.12676046.1486753542000@Atlassian.JIRA>
References: <JIRA.12676046.1486753542000@Atlassian.JIRA>
	<JIRA.12676046.1486753542774@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676046.1486753542000.97488.1486753560206@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-32:
--------------------------------------

             Summary: Cassandra and Metrics Serice Restarts During Initialization
                 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  Fri Feb 10 14:37:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Fri, 10 Feb 2017 14:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema
	Test
In-Reply-To: <JIRA.12676046.1486753543000@Atlassian.JIRA>
References: <JIRA.12676046.1486753543000@Atlassian.JIRA>
	<JIRA.12676046.1486753543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676046.1486753543000.97576.1486755420292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Mahoney updated HAWKULARQE-32:
-----------------------------------
    Summary: Cassandra/Hawkular Schema Test  (was: Cassandra and Metrics Serice Restarts During Initialization)


> 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  Fri Feb 10 14:40:00 2017
From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=)
Date: Fri, 10 Feb 2017 14:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1435) Runtime Exception while
 validating a file with Knowlge source
In-Reply-To: <JIRA.12676050.1486755598000@Atlassian.JIRA>
References: <JIRA.12676050.1486755598000@Atlassian.JIRA>
	<JIRA.12676050.1486755598698@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676050.1486755598000.97586.1486755600171@Atlassian.JIRA>

M?lanie Gauthier created DROOLS-1435:
----------------------------------------

             Summary: Runtime Exception while validating a file with Knowlge source
                 Key: DROOLS-1435
                 URL: https://issues.jboss.org/browse/DROOLS-1435
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: M?lanie Gauthier
            Assignee: Edson Tirelli
         Attachments: Cardamage_ks.dmn

When validating the attached file, the following exception is raised:

java.lang.RuntimeException: Error evaluating constraint 'id == rightOfHash( $oc.href )' in [Rule "REQAUTH_NOT_KNOWLEDGESOURCE" in rules.drl]

If I remove the Knowledge Sources, the validation runs fine.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 10 14:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 10 Feb 2017 14:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-53) GSSAPI Make Delegated Credential
	Available
In-Reply-To: <JIRA.12544905.1403786422000@Atlassian.JIRA>
References: <JIRA.12544905.1403786422000@Atlassian.JIRA>
	<JIRA.12544905.1403786422000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544905.1403786422000.97593.1486755960591@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-53:
-----------------------------------

    Assignee: Darran Lofthouse


> GSSAPI Make Delegated Credential Available
> ------------------------------------------
>
>                 Key: ELY-53
>                 URL: https://issues.jboss.org/browse/ELY-53
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta25
>
>
> The server side of the mechanism can receive a delegated credential but there is no way to obtain it, we should provide a way for it to be obtained or provided.
> _Note: This may be an Elytron integration point rather than something supported in the pure SASL mechanism._



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:15:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 15:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2286)
 GenericSubsystemDescribeHandler generates duplicates operations for
 override models
In-Reply-To: <JIRA.12676052.1486757674000@Atlassian.JIRA>
References: <JIRA.12676052.1486757674000@Atlassian.JIRA>
	<JIRA.12676052.1486757674791@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676052.1486757674000.97665.1486757700130@Atlassian.JIRA>

Paul Ferraro created WFCORE-2286:
------------------------------------

             Summary: GenericSubsystemDescribeHandler generates duplicates operations for override models
                 Key: WFCORE-2286
                 URL: https://issues.jboss.org/browse/WFCORE-2286
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.0.Alpha24
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:21:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Feb 2017 15:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.97680.1486758060325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-972:
---------------------------------------

    Assignee: Brian Stansberry  (was: Heiko Braun)


> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:35:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 15:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2286)
 GenericSubsystemDescribeHandler generates duplicates operations for
 override models
In-Reply-To: <JIRA.12676052.1486757675000@Atlassian.JIRA>
References: <JIRA.12676052.1486757675000@Atlassian.JIRA>
	<JIRA.12676052.1486757675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676052.1486757675000.97692.1486758900063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFCORE-2286:
---------------------------------
    Description: Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.  Additionally, child order needs to be preserved, even in the presence of override models.  (was: Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.)


> GenericSubsystemDescribeHandler generates duplicates operations for override models
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2286
>                 URL: https://issues.jboss.org/browse/WFCORE-2286
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha24
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.  Additionally, child order needs to be preserved, even in the presence of override models.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:36:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 15:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2286)
 GenericSubsystemDescribeHandler generates duplicates operations for
 override models
In-Reply-To: <JIRA.12676052.1486757675000@Atlassian.JIRA>
References: <JIRA.12676052.1486757675000@Atlassian.JIRA>
	<JIRA.12676052.1486757675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676052.1486757675000.97695.1486758960125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned WFCORE-2286:
------------------------------------

    Assignee: Brian Stansberry  (was: Paul Ferraro)


> GenericSubsystemDescribeHandler generates duplicates operations for override models
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2286
>                 URL: https://issues.jboss.org/browse/WFCORE-2286
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha24
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.  Additionally, child order needs to be preserved, even in the presence of override models.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:44:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 10 Feb 2017 15:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8079) DeploymentScanner failure
 during reconfiguring using embed-server
In-Reply-To: <JIRA.12676056.1486759399000@Atlassian.JIRA>
References: <JIRA.12676056.1486759399000@Atlassian.JIRA>
	<JIRA.12676056.1486759399640@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676056.1486759399000.97767.1486759440763@Atlassian.JIRA>

Josef Cacek created WFLY-8079:
---------------------------------

             Summary: DeploymentScanner failure during reconfiguring using embed-server
                 Key: WFLY-8079
                 URL: https://issues.jboss.org/browse/WFLY-8079
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Josef Cacek
            Assignee: Brian Stansberry
            Priority: Critical


Running a JBoss CLI script with embed-server led to DeploymentScanner (intermittent) failure:

{code}
2017-02-10 21:16:00,591 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /home/kwart/projects/wildfly/wildfly/testsuite/integration/smoke/target/jbossas/standalone/deployments threw Exception: java.lang.IllegalStateException
	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
	at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:59)
	at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:711)
	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:701)
	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.lambda$execute$0(DefaultDeploymentOperations.java:158)
	at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.execute(DefaultDeploymentOperations.java:158)
	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.execute(DefaultDeploymentOperations.java:137)
	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:81)
	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1685)
	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1634)
	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.forcedUndeployScan(FileSystemDeploymentService.java:519)
	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:770)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	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}

*Background:*
We use {{enable-elytron.cli}}  script to reconfigure server profiles (default and full) in the testsuite to run with Elytron provided security.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 15:46:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 10 Feb 2017 15:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2287) DeploymentScanner failure
 during reconfiguring using embed-server
In-Reply-To: <JIRA.12676056.1486759400000@Atlassian.JIRA>
References: <JIRA.12676056.1486759400000@Atlassian.JIRA>
	<JIRA.12676056.1486759400000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676056.1486759400000.97782.1486759560416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-8079 to WFCORE-2287:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2287  (was: WFLY-8079)
    Component/s: Domain Management
                 Security
                     (was: Domain Management)
                     (was: Security)


> DeploymentScanner failure during reconfiguring using embed-server
> -----------------------------------------------------------------
>
>                 Key: WFCORE-2287
>                 URL: https://issues.jboss.org/browse/WFCORE-2287
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Josef Cacek
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Running a JBoss CLI script with embed-server led to DeploymentScanner (intermittent) failure:
> {code}
> 2017-02-10 21:16:00,591 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /home/kwart/projects/wildfly/wildfly/testsuite/integration/smoke/target/jbossas/standalone/deployments threw Exception: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> 	at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:59)
> 	at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:711)
> 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:701)
> 	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.lambda$execute$0(DefaultDeploymentOperations.java:158)
> 	at org.jboss.as.controller.access.InVmAccess.runInVm(InVmAccess.java:85)
> 	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations$ControllerClient$1.execute(DefaultDeploymentOperations.java:158)
> 	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.execute(DefaultDeploymentOperations.java:137)
> 	at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getDeploymentsStatus(DefaultDeploymentOperations.java:81)
> 	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1685)
> 	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1634)
> 	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.forcedUndeployScan(FileSystemDeploymentService.java:519)
> 	at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:770)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 	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}
> *Background:*
> We use {{enable-elytron.cli}}  script to reconfigure server profiles (default and full) in the testsuite to run with Elytron provided security.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 16:30:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 10 Feb 2017 16:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-902) Deployment fails when
 unreachable LDAP is used for Elytron LDAP authentication and
 ldap-realm.direct-verification=true
In-Reply-To: <JIRA.12674086.1485941628000@Atlassian.JIRA>
References: <JIRA.12674086.1485941628000@Atlassian.JIRA>
	<JIRA.12674086.1485941628000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674086.1485941628000.97840.1486762200186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-902:
---------------------------
    Fix Version/s: 1.1.0.Beta24


> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication and ldap-realm.direct-verification=true
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-902
>                 URL: https://issues.jboss.org/browse/ELY-902
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 1.1.0.Beta24
>
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses ldap-realm with direct-verification=true and which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) 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: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
> 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$4(ApplicationSecurityDomainDefinition.java:416)
> 	at java.lang.Iterable.forEach(Iterable.java:75)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:413)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:356)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:409)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:209)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 	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:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> 	... 8 more
> ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) 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.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
>     "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"]
> }
> {code}
> It is similar issue as ELY-668 - the difference is that {{direct-verification=true}} is configured in current issue.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 16:51:00 2017
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Fri, 10 Feb 2017 16:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6671) ajp connection hangs if a
 post HTTP request header contains 'Transfer-Encoding: chunked'
In-Reply-To: <JIRA.12629562.1464982833000@Atlassian.JIRA>
References: <JIRA.12629562.1464982833000@Atlassian.JIRA>
	<JIRA.12629562.1464982833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629562.1464982833000.97848.1486763460469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Ogburn reopened WFLY-6671:
--------------------------------


I reproduced this with EAP 7.0.4 + JBCS httpd/mod_jk as well.  mod_proxy_ajp works.  Inspecting tcp dumps, I see a potential difference to explain this.  The last empty body message sent by mod_jk is the following:

12 34 00 00

So it just says no message length, but undertow doesn't seem to interpret this as a signal to end its request body read.

Compared to mod_proxy_ajp, it sends the following for the final body message:

12 34 00 02 00 00

So mod_proxy_ajp seems to say it has a body length of 2 bytes (which are empty) and undertow ends its request body read after seeing this.  Does undertow need a change to recognize mod_jk's end body message too?

> ajp connection hangs if a post HTTP request header contains  'Transfer-Encoding: chunked'
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-6671
>                 URL: https://issues.jboss.org/browse/WFLY-6671
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.0.0.Final
>         Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
>            Reporter: river shen
>            Assignee: Stuart Douglas
>         Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties
>
>
> When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
> if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. 
> It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
> We have attached a minimal web application that reproduce this issue.
> Also attached is the standalone.xml  and the apache configuration file.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 16:59:00 2017
From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=)
Date: Fri, 10 Feb 2017 16:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1436) Unable to create runtime
 for the attached DMN model
In-Reply-To: <JIRA.12676071.1486763914000@Atlassian.JIRA>
References: <JIRA.12676071.1486763914000@Atlassian.JIRA>
	<JIRA.12676071.1486763914529@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676071.1486763914000.97853.1486763940157@Atlassian.JIRA>

M?lanie Gauthier created DROOLS-1436:
----------------------------------------

             Summary: Unable to create runtime for the attached DMN model
                 Key: DROOLS-1436
                 URL: https://issues.jboss.org/browse/DROOLS-1436
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: M?lanie Gauthier
            Assignee: Edson Tirelli
         Attachments: Get Viable Loan Products.dmn

When trying to load that model, the following errors is logged:
 java.lang.IllegalStateException: [Message [id=1, kieBase=defaultKieBase, level=ERROR, path=trisotech/Get_Viable_Loan_Products.dmn, line=-1, column=0
   text=Unable to compile DMN model for the resource]]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 10 18:03:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 10 Feb 2017 18:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2288) Indexed adds for override
 models of ordered child types does not work
In-Reply-To: <JIRA.12676073.1486767723000@Atlassian.JIRA>
References: <JIRA.12676073.1486767723000@Atlassian.JIRA>
	<JIRA.12676073.1486767723048@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676073.1486767723000.97913.1486767780146@Atlassian.JIRA>

Paul Ferraro created WFCORE-2288:
------------------------------------

             Summary: Indexed adds for override models of ordered child types does not work
                 Key: WFCORE-2288
                 URL: https://issues.jboss.org/browse/WFCORE-2288
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 3.0.0.Alpha24
            Reporter: Paul Ferraro
            Assignee: Brian Stansberry


This is due to the following logic in AbstractAddStepHandler:
{noformat}
    protected Resource createResource(final OperationContext context, final ModelNode operation) {
        ImmutableManagementResourceRegistration registration = context.getResourceRegistration();
        if (registration != null) {
            Set<String> orderedChildTypes = registration.getOrderedChildTypes();
            boolean orderedChildResource = registration.isOrderedChildResource();
            if (orderedChildResource || orderedChildTypes.size() > 0) {
                return new OrderedResourceCreator(orderedChildResource, orderedChildTypes).createResource(context, operation);
            }
        }
        return createResource(context);
    }
{noformat}

Override models fail to use the OrderedResourceCreator because registration.isOrderedChildResource() returns false.

There are a number of ways to handle this:
1. Allow override model registration to indicate that they are ordered.  Currently, the MRR implementation throws an exception if an override model registration tries to specify that it is ordered, and the corresponding wildcard registration is ordered.
2. Auto-set override model registrations to be ordered if the corresponding wildcard registration is ordered.
3. In AbstractAddStepHandler, when determining whether or not to use an OrderedResourceCreator, test if either registration.isOrderedChildResource() is true *or*, if a wildcard registration exists, check if its registration.isOrderedChildResource() is true.

Of these three options, #3 is probably the easiest, and most sensible solution.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 10 20:05:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 10 Feb 2017 20:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8080) ajp connection hangs if a
 post HTTP request header contains 'Transfer-Encoding: chunked'
In-Reply-To: <JIRA.12676075.1486775083000@Atlassian.JIRA>
References: <JIRA.12676075.1486775083000@Atlassian.JIRA>
	<JIRA.12676075.1486775083173@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676075.1486775083000.97969.1486775100248@Atlassian.JIRA>

Stuart Douglas created WFLY-8080:
------------------------------------

             Summary: ajp connection hangs if a post HTTP request header contains  'Transfer-Encoding: chunked'
                 Key: WFLY-8080
                 URL: https://issues.jboss.org/browse/WFLY-8080
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.0.0.Final
         Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
            Reporter: river shen
            Assignee: Stuart Douglas


When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. 

It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.

We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml  and the apache configuration file.






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 03:56:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Sat, 11 Feb 2017 03:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1435) Runtime Exception while
 validating a file with Knowlge source
In-Reply-To: <JIRA.12676050.1486755599000@Atlassian.JIRA>
References: <JIRA.12676050.1486755599000@Atlassian.JIRA>
	<JIRA.12676050.1486755599000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676050.1486755599000.97991.1486803360644@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-1435:
--------------------------------------

    Assignee: Matteo Mortari  (was: Edson Tirelli)


> Runtime Exception while validating a file with Knowlge source
> -------------------------------------------------------------
>
>                 Key: DROOLS-1435
>                 URL: https://issues.jboss.org/browse/DROOLS-1435
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: M?lanie Gauthier
>            Assignee: Matteo Mortari
>         Attachments: Cardamage_ks.dmn
>
>
> When validating the attached file, the following exception is raised:
> java.lang.RuntimeException: Error evaluating constraint 'id == rightOfHash( $oc.href )' in [Rule "REQAUTH_NOT_KNOWLEDGESOURCE" in rules.drl]
> If I remove the Knowledge Sources, the validation runs fine.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Sat Feb 11 06:32:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 06:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within
	HTTP API
In-Reply-To: <JIRA.12676078.1486812681000@Atlassian.JIRA>
References: <JIRA.12676078.1486812681000@Atlassian.JIRA>
	<JIRA.12676078.1486812681149@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676078.1486812681000.98006.1486812720146@Atlassian.JIRA>

Darran Lofthouse created ELY-942:
------------------------------------

             Summary: 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.Beta24


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  Sat Feb 11 07:13:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 07:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7833) Coverity: dereference null
 value in PermissionMapperDefinitions (Elytron subsystem)
In-Reply-To: <JIRA.12668052.1481897776000@Atlassian.JIRA>
References: <JIRA.12668052.1481897776000@Atlassian.JIRA>
	<JIRA.12668052.1481897776000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668052.1481897776000.98014.1486815181121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-7833:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Coverity: dereference null value in PermissionMapperDefinitions (Elytron subsystem)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-7833
>                 URL: https://issues.jboss.org/browse/WFLY-7833
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 11.0.0.Alpha1
>
>
> Coverity static-analysis scan found a possilbe method call on null object in the {{PermissionMapperDefinitions.createPermission}} method.
> https://scan7.coverity.com/reports.htm#v16159/p12663/fileInstanceId=6892117&defectInstanceId=1794524&mergedDefectId=1388481
> {code:java}
> Module currentModule = Module.getCallerModule();
> if (permission.getModule() != null) {
>     ModuleIdentifier mi = ModuleIdentifier.fromString(permission.getModule());
>     try {
>         currentModule = currentModule.getModule(mi);
> {code}
> The {{currentModule}} value returned from {{Module.getCallerModule()}} may be {{null}}. The {{getModule()}} method is called on it without the null-check.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:02:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-943) Release WildFly Elytron
	1.1.0.Beta24
In-Reply-To: <JIRA.12676110.1486818062000@Atlassian.JIRA>
References: <JIRA.12676110.1486818062000@Atlassian.JIRA>
	<JIRA.12676110.1486818062369@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676110.1486818062000.21.1486818120675@Atlassian.JIRA>

Darran Lofthouse created ELY-943:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta24
                 Key: ELY-943
                 URL: https://issues.jboss.org/browse/ELY-943
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta24






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:14:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-943) Release WildFly Elytron
	1.1.0.Beta24
In-Reply-To: <JIRA.12676110.1486818062000@Atlassian.JIRA>
References: <JIRA.12676110.1486818062000@Atlassian.JIRA>
	<JIRA.12676110.1486818062000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676110.1486818062000.25.1486818840262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-943.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta24
> ------------------------------------
>
>                 Key: ELY-943
>                 URL: https://issues.jboss.org/browse/ELY-943
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta24
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-941) Allow provider name to be null
 in SSLContextBuilder
In-Reply-To: <JIRA.12676008.1486741944000@Atlassian.JIRA>
References: <JIRA.12676008.1486741944000@Atlassian.JIRA>
	<JIRA.12676008.1486741944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676008.1486741944000.30.1486818903952@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-941:
---------------------------------
    Fix Version/s: 1.1.0.Beta25
                       (was: 1.1.0.Beta24)


> Allow provider name to be null in SSLContextBuilder
> ---------------------------------------------------
>
>                 Key: ELY-941
>                 URL: https://issues.jboss.org/browse/ELY-941
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SSL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta25
>
>
> The utility searching for the provider takes 'null' to mean any provider allowed so a 'null' value should be allowed.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within
	HTTP API
In-Reply-To: <JIRA.12676078.1486812681000@Atlassian.JIRA>
References: <JIRA.12676078.1486812681000@Atlassian.JIRA>
	<JIRA.12676078.1486812681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676078.1486812681000.27.1486818903812@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-940) key-store-ssl-certificate ->
 key-store-clear-password is wrapping parsing inside the Supplier
In-Reply-To: <JIRA.12675882.1486696660000@Atlassian.JIRA>
References: <JIRA.12675882.1486696660000@Atlassian.JIRA>
	<JIRA.12675882.1486696660000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675882.1486696660000.33.1486818904066@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-940:
---------------------------------
    Fix Version/s: 1.1.0.Beta25
                       (was: 1.1.0.Beta24)


> key-store-ssl-certificate -> key-store-clear-password is wrapping parsing inside the Supplier
> ---------------------------------------------------------------------------------------------
>
>                 Key: ELY-940
>                 URL: https://issues.jboss.org/browse/ELY-940
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta25
>
>
> This means we get errors like this where the parser is accessed after parsing should have finished: -
> {{[disconnected /] connect
> java.lang.IllegalStateException: Current event not START_ELEMENT
> 	at com.ctc.wstx.sr.BasicStreamReader.getAttributeCount(BasicStreamReader.java:584)
> 	at org.wildfly.client.config.BasicXMLStreamReader.getAttributeCount(BasicXMLStreamReader.java:191)
> 	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> 	at org.wildfly.client.config.AbstractDelegatingXMLStreamReader.getAttributeCount(AbstractDelegatingXMLStreamReader.java:148)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseClearPassword(ElytronXmlParser.java:1864)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$43(ElytronXmlParser.java:1270)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseKeyStoreRefType$44(ElytronXmlParser.java:1286)
> 	at org.wildfly.security.auth.client.ElytronXmlParser$PrivateKeyKeyStoreEntryCredentialFactory.get(ElytronXmlParser.java:2232)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextType$5(ElytronXmlParser.java:434)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseSslContextRuleType$6(ElytronXmlParser.java:457)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:493)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:292)
> }}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support
 standard KeyManager instances
In-Reply-To: <JIRA.12675881.1486695345000@Atlassian.JIRA>
References: <JIRA.12675881.1486695345000@Atlassian.JIRA>
	<JIRA.12675881.1486695345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675881.1486695345000.36.1486818904177@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication
 client should not mandate an input source
In-Reply-To: <JIRA.12675879.1486694444000@Atlassian.JIRA>
References: <JIRA.12675879.1486694444000@Atlassian.JIRA>
	<JIRA.12675879.1486694444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675879.1486694444000.39.1486818904319@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication
 client has no trust configuration
In-Reply-To: <JIRA.12675878.1486694187000@Atlassian.JIRA>
References: <JIRA.12675878.1486694187000@Atlassian.JIRA>
	<JIRA.12675878.1486694187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675878.1486694187000.42.1486818904435@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of
 CLIENT_CERT authentication for SASL
In-Reply-To: <JIRA.12675877.1486693276000@Atlassian.JIRA>
References: <JIRA.12675877.1486693276000@Atlassian.JIRA>
	<JIRA.12675877.1486693276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675877.1486693276000.45.1486818904559@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.48.1486818904626@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.51.1486818904754@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.55.1486818904920@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.1.0.Beta25
                       (was: 1.1.0.Beta24)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta25
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.58.1486818905058@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.61.1486818905166@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.64.1486818905230@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.67.1486818905369@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.71.1486818905454@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.74.1486818905558@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.77.1486818905661@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.80.1486818905812@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.85.1486818905955@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.89.1486818906078@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.92.1486818906138@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.96.1486818906251@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.100.1486818906402@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.103.1486818906548@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15: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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.106.1486818906695@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.136.1486818907663@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15: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: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.109.1486818906816@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.113.1486818906889@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.130.1486818907474@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler
 interactions to a common base class for HTTP mechanisms, .
In-Reply-To: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.123.1486818907289@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.126.1486818907386@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.133.1486818907570@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.116.1486818907022@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be
 considered to be static nested in Elytron
In-Reply-To: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.147.1486818908101@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.120.1486818907194@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.140.1486818907785@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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
>             Fix For: 1.1.0.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.155.1486818908335@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.143.1486818907931@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.152.1486818908271@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.158.1486818908429@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.161.1486818908485@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.164.1486818908580@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.171.1486818908784@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.168.1486818908679@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the
 'org.wildfly.security.mechanism' package and sub packages.
In-Reply-To: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.174.1486818908888@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.180.1486818909092@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the
 'org.wildfly.security.credential' package and sub packages.
In-Reply-To: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.177.1486818909030@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.183.1486818909181@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.188.1486818909357@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.191.1486818909493@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.198.1486818909700@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> 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  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.195.1486818909649@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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  Sat Feb 11 08:15:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.201.1486818909837@Atlassian.JIRA>


     [ 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.Beta25
                       (was: 1.1.0.Beta24)


> 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.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:15:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:15:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-37) Audit Logging Integration
In-Reply-To: <JIRA.12548096.1406826316000@Atlassian.JIRA>
References: <JIRA.12548096.1406826316000@Atlassian.JIRA>
	<JIRA.12548096.1406826316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12548096.1406826316000.206.1486818910051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-37:
--------------------------------
    Fix Version/s: 1.1.0.Beta25
                       (was: 1.1.0.Beta24)


> Audit Logging Integration
> -------------------------
>
>                 Key: ELY-37
>                 URL: https://issues.jboss.org/browse/ELY-37
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: API / SPI, Audit
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.1.0.Beta25
>
>
> Implement into Elytron samething like:
> https://github.com/picketbox/picketbox/tree/master/security-spi/spi/src/main/java/org/jboss/security/audit
> or
> https://github.com/wildfly/wildfly-core/tree/master/controller/src/main/java/org/jboss/as/controller/audit
> or
> https://github.com/kabir/tamper-detecting-audit-log
> UPDATE:
> By discussion should be based on currently not implemented processing of **security events** - depends on it from now.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:18:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2289) Upgrade to WildFly Elytron
	1.1.0.Beta24
In-Reply-To: <JIRA.12676111.1486819074000@Atlassian.JIRA>
References: <JIRA.12676111.1486819074000@Atlassian.JIRA>
	<JIRA.12676111.1486819074801@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676111.1486819074000.209.1486819080196@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2289:
----------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta24
                 Key: WFCORE-2289
                 URL: https://issues.jboss.org/browse/WFCORE-2289
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:19:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2290) Merge latest WildFly
 Elytron Integration Changes
In-Reply-To: <JIRA.12676112.1486819120000@Atlassian.JIRA>
References: <JIRA.12676112.1486819120000@Atlassian.JIRA>
	<JIRA.12676112.1486819120829@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676112.1486819120000.224.1486819140952@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2290:
----------------------------------------

             Summary: Merge latest WildFly Elytron Integration Changes
                 Key: WFCORE-2290
                 URL: https://issues.jboss.org/browse/WFCORE-2290
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Alpha25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 08:22:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8081) Merge latest WildFly Elytron
 integration changes
In-Reply-To: <JIRA.12676113.1486819290000@Atlassian.JIRA>
References: <JIRA.12676113.1486819290000@Atlassian.JIRA>
	<JIRA.12676113.1486819290190@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676113.1486819290000.251.1486819320382@Atlassian.JIRA>

Darran Lofthouse created WFLY-8081:
--------------------------------------

             Summary: Merge latest WildFly Elytron integration changes
                 Key: WFLY-8081
                 URL: https://issues.jboss.org/browse/WFLY-8081
             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  Sat Feb 11 08:23:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 08:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8082) Upgrade to Elytron Subsystem
	1.0.0.Beta6
In-Reply-To: <JIRA.12676114.1486819343000@Atlassian.JIRA>
References: <JIRA.12676114.1486819343000@Atlassian.JIRA>
	<JIRA.12676114.1486819343616@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676114.1486819343000.264.1486819380212@Atlassian.JIRA>

Darran Lofthouse created WFLY-8082:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Beta6
                 Key: WFLY-8082
                 URL: https://issues.jboss.org/browse/WFLY-8082
             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  Sat Feb 11 09:54:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sat, 11 Feb 2017 09:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.312.1486824840129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-1432:
----------------------------------
    Summary: Improve error messages when compiling models with errors  (was: Improve error messages when compiling modes with errors)


> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 10:33:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8083) WebMigrateOperation makes
 invalid assumption about web subsystem "describe" output ordering
In-Reply-To: <JIRA.12676119.1486827149000@Atlassian.JIRA>
References: <JIRA.12676119.1486827149000@Atlassian.JIRA>
	<JIRA.12676119.1486827149861@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676119.1486827149000.314.1486827180086@Atlassian.JIRA>

Brian Stansberry created WFLY-8083:
--------------------------------------

             Summary: WebMigrateOperation makes invalid assumption about web subsystem "describe" output ordering
                 Key: WFLY-8083
                 URL: https://issues.jboss.org/browse/WFLY-8083
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.1.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The WebMigrateOperation iterates over the operations produced by running 'describe' against the web subsystem, checking different operations and converting them. When it gets to a /subsystem=web/host=* op it processes that in its migrateVirtualHost method. But that method as part of its work checks all the other *already migrated* ops looking for path filters and the access log valve. If found it adds additional child resource add ops.

This is flawed because it assumes any add op for an access log valve or path filter will have already been created when migrateVirtualHost is run. That's not a valid assumption as there is nothing in the contract of the describe operation that guarantees such an order in its output. Work on WFCORE-2286 has revealed this.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 10:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 10:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8084)
 ExpressionSupportSmokeTestCase needs to skip outflow-anonymous attribute of
 Elytron Subsystem
In-Reply-To: <JIRA.12676120.1486828240000@Atlassian.JIRA>
References: <JIRA.12676120.1486828240000@Atlassian.JIRA>
	<JIRA.12676120.1486828240021@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676120.1486828240000.331.1486828260268@Atlassian.JIRA>

Darran Lofthouse created WFLY-8084:
--------------------------------------

             Summary: ExpressionSupportSmokeTestCase needs to skip outflow-anonymous attribute of Elytron Subsystem
                 Key: WFLY-8084
                 URL: https://issues.jboss.org/browse/WFLY-8084
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.0.0.Alpha1


This attribute can only be set if outflow-security-domains is also defined, as outflow-security-domains is a capability reference it does not support expressions so can not be set in this test case.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 11:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 11 Feb 2017 11:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8084)
 ExpressionSupportSmokeTestCase needs to skip outflow-anonymous attribute of
 Elytron Subsystem
In-Reply-To: <JIRA.12676120.1486828240000@Atlassian.JIRA>
References: <JIRA.12676120.1486828240000@Atlassian.JIRA>
	<JIRA.12676120.1486828240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676120.1486828240000.422.1486831860231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8084:
-----------------------------------
    Labels: affects_elytron  (was: )


> ExpressionSupportSmokeTestCase needs to skip outflow-anonymous attribute of Elytron Subsystem
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8084
>                 URL: https://issues.jboss.org/browse/WFLY-8084
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: affects_elytron
>             Fix For: 11.0.0.Alpha1
>
>
> This attribute can only be set if outflow-security-domains is also defined, as outflow-security-domains is a capability reference it does not support expressions so can not be set in this test case.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 12:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 12:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8085)
 ExpressionSupportSmokeTestCase doesn't properly handle attributes with
 undefined required attributes
In-Reply-To: <JIRA.12676124.1486832874000@Atlassian.JIRA>
References: <JIRA.12676124.1486832874000@Atlassian.JIRA>
	<JIRA.12676124.1486832874557@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676124.1486832874000.424.1486832880067@Atlassian.JIRA>

Brian Stansberry created WFLY-8085:
--------------------------------------

             Summary: ExpressionSupportSmokeTestCase doesn't properly handle attributes with undefined required attributes
                 Key: WFLY-8085
                 URL: https://issues.jboss.org/browse/WFLY-8085
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Test Suite
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


ExpressionSupportSmokeTestCase is attempting to set attributes even when other required attributes are undefined. In organizeAttributes it checks if the required attribute is undefined due to the presence of a defined alternative, but if that's not the reason it tries to set the base attribute. That will fail if the required attribute is undefined simply because the base config doesn't define it.

https://github.com/wildfly/wildfly/pull/9628 includes a workaround for this, but it's not ideal. We should look into how setExpressions works and change it from executing a bunch of individual write-attribute ops per resource to executing them all as steps in a single composite. That would remove any reason for leaving these attributes undefined. Both the base attribute and the required attribute would be set in the same composite.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 12:19:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Sat, 11 Feb 2017 12:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.428.1486833540130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362229#comment-13362229 ] 

Harald Pehl commented on WFCORE-972:
------------------------------------

We have a working solution right now and as soon as this is in core we'd need a bit of refactoring on the client side anyway. So from a HAL POV it's ok if this gets merged for Core 4.  

> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 12:29:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 12:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8085)
 ExpressionSupportSmokeTestCase doesn't properly handle attributes with
 undefined required attributes
In-Reply-To: <JIRA.12676124.1486832875000@Atlassian.JIRA>
References: <JIRA.12676124.1486832875000@Atlassian.JIRA>
	<JIRA.12676124.1486832875000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676124.1486832875000.437.1486834140319@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362232#comment-13362232 ] 

Brian Stansberry commented on WFLY-8085:
----------------------------------------

Using a composite alone isn't enough here. We also need to deal with other reasons why the required attribute is invalid; e.g. it's a capability reference etc.

If the undefined required attribute has a default value we could set it to that. If it doesn't, we can't set it regardless. But a required attribute would be undefined but with a default value is either 1) illegal for reasons I'm too lazy to think through now, or 2) a sign of a bad smelling management API and a real edge case. So, I won't bother dealing with that.

Closing.

> ExpressionSupportSmokeTestCase doesn't properly handle attributes with undefined required attributes
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8085
>                 URL: https://issues.jboss.org/browse/WFLY-8085
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> ExpressionSupportSmokeTestCase is attempting to set attributes even when other required attributes are undefined. In organizeAttributes it checks if the required attribute is undefined due to the presence of a defined alternative, but if that's not the reason it tries to set the base attribute. That will fail if the required attribute is undefined simply because the base config doesn't define it.
> https://github.com/wildfly/wildfly/pull/9628 includes a workaround for this, but it's not ideal. We should look into how setExpressions works and change it from executing a bunch of individual write-attribute ops per resource to executing them all as steps in a single composite. That would remove any reason for leaving these attributes undefined. Both the base attribute and the required attribute would be set in the same composite.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 12:29:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 12:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8085)
 ExpressionSupportSmokeTestCase doesn't properly handle attributes with
 undefined required attributes
In-Reply-To: <JIRA.12676124.1486832875000@Atlassian.JIRA>
References: <JIRA.12676124.1486832875000@Atlassian.JIRA>
	<JIRA.12676124.1486832875000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676124.1486832875000.439.1486834140364@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-8085.
------------------------------------
    Resolution: Won't Fix


> ExpressionSupportSmokeTestCase doesn't properly handle attributes with undefined required attributes
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8085
>                 URL: https://issues.jboss.org/browse/WFLY-8085
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> ExpressionSupportSmokeTestCase is attempting to set attributes even when other required attributes are undefined. In organizeAttributes it checks if the required attribute is undefined due to the presence of a defined alternative, but if that's not the reason it tries to set the base attribute. That will fail if the required attribute is undefined simply because the base config doesn't define it.
> https://github.com/wildfly/wildfly/pull/9628 includes a workaround for this, but it's not ideal. We should look into how setExpressions works and change it from executing a bunch of individual write-attribute ops per resource to executing them all as steps in a single composite. That would remove any reason for leaving these attributes undefined. Both the base attribute and the required attribute would be set in the same composite.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 20:07:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 20:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8086) WebMigrateOperation makes
 invalid assumption about web subsystem "describe" output ordering
In-Reply-To: <JIRA.12676127.1486861586000@Atlassian.JIRA>
References: <JIRA.12676127.1486861586000@Atlassian.JIRA>
	<JIRA.12676127.1486861586711@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676127.1486861586000.676.1486861620089@Atlassian.JIRA>

Brian Stansberry created WFLY-8086:
--------------------------------------

             Summary: WebMigrateOperation makes invalid assumption about web subsystem "describe" output ordering
                 Key: WFLY-8086
                 URL: https://issues.jboss.org/browse/WFLY-8086
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.1.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The WebMigrateOperation iterates over the operations produced by running 'describe' against the web subsystem, checking different operations and converting them. When it gets to a /subsystem=web/host=* op it processes that in its migrateVirtualHost method. But that method as part of its work checks all the other *already migrated* ops looking for path filters and the access log valve. If found it adds additional child resource add ops.

This is flawed because it assumes any add op for an access log valve or path filter will have already been created when migrateVirtualHost is run. That's not a valid assumption as there is nothing in the contract of the describe operation that guarantees such an order in its output. Work on WFCORE-2286 has revealed this.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 21:25:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 21:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly
 handles duplicate module names
In-Reply-To: <JIRA.12643479.1471302678000@Atlassian.JIRA>
References: <JIRA.12643479.1471302678000@Atlassian.JIRA>
	<JIRA.12643479.1471302678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643479.1471302678000.761.1486866300314@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1717:
----------------------------------------

    Assignee: Brian Stansberry


> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
>                 Key: WFCORE-1717
>                 URL: https://issues.jboss.org/browse/WFCORE-1717
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
>            Reporter: Toby Crawley
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.CR1
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 11 21:44:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 11 Feb 2017 21:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly
 handles duplicate module names
In-Reply-To: <JIRA.12643479.1471302678000@Atlassian.JIRA>
References: <JIRA.12643479.1471302678000@Atlassian.JIRA>
	<JIRA.12643479.1471302678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643479.1471302678000.765.1486867440193@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1717:
-------------------------------------
    Fix Version/s: 3.0.0.Alpha25
                       (was: 3.0.0.CR1)


> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
>                 Key: WFCORE-1717
>                 URL: https://issues.jboss.org/browse/WFCORE-1717
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
>            Reporter: Toby Crawley
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha25
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 08:29:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 08:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8087) Statistics Resources are
 being created without a corresponding ManagementResourceRegistration
In-Reply-To: <JIRA.12676129.1486906132000@Atlassian.JIRA>
References: <JIRA.12676129.1486906132000@Atlassian.JIRA>
	<JIRA.12676129.1486906132165@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676129.1486906132000.780.1486906140232@Atlassian.JIRA>

Brian Stansberry created WFLY-8087:
--------------------------------------

             Summary: Statistics Resources are being created without a corresponding ManagementResourceRegistration
                 Key: WFLY-8087
                 URL: https://issues.jboss.org/browse/WFLY-8087
             Project: WildFly
          Issue Type: Bug
          Components: JCA, JMS
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.

I found there were no MRRs for

/profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
/profile=*/subsystem=datasources/data-source=*/statistics=jdbc
/profile=*/subsystem=datasources/data-source=*/statistics=pool

I expect the latter two would be repeated for xa-data-source=*

Probably the lack of MRR is correct and the problem is the existence of the resource. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:02 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2281) Add
	wildfly-elytron.tool.jar to bin
In-Reply-To: <JIRA.12675785.1486653266000@Atlassian.JIRA>
References: <JIRA.12675785.1486653266000@Atlassian.JIRA>
	<JIRA.12675785.1486653266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675785.1486653266000.792.1486912802893@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2281:
-------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 3.0.0.Alpha25)


> Add wildfly-elytron.tool.jar to bin
> -----------------------------------
>
>                 Key: WFCORE-2281
>                 URL: https://issues.jboss.org/browse/WFCORE-2281
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.799.1486912803183@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.807.1486912803446@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.810.1486912803506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2217:
-------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 3.0.0.Alpha25)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta1, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Sun Feb 12 10:20:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.817.1486912803844@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:04 -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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.824.1486912804138@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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  Sun Feb 12 10:20:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.834.1486912804540@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.843.1486912804861@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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  Sun Feb 12 10:20:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.849.1486912805013@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.857.1486912805294@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>         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  Sun Feb 12 10:20:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:05 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.865.1486912805574@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.868.1486912805659@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta1
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.875.1486912805922@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1964:
-------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 3.0.0.Alpha25)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta1
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.880.1486912806131@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:06 -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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.887.1486912806303@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.893.1486912806547@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.901.1486912806871@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly
 handles duplicate module names
In-Reply-To: <JIRA.12643479.1471302678000@Atlassian.JIRA>
References: <JIRA.12643479.1471302678000@Atlassian.JIRA>
	<JIRA.12643479.1471302678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643479.1471302678000.905.1486912806988@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1717:
-------------------------------------
    Fix Version/s: 3.0.0.Beta1
                       (was: 3.0.0.Alpha25)


> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
>                 Key: WFCORE-1717
>                 URL: https://issues.jboss.org/browse/WFCORE-1717
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
>            Reporter: Toby Crawley
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta1
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 10:20:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:07 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.925.1486912807443@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>         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  Sun Feb 12 10:20:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.930.1486912807575@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:07 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.916.1486912807265@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Beta1
>
>         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  Sun Feb 12 10:20:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.934.1486912807687@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 10:20:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.941.1486912807946@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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.<init>(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  Sun Feb 12 10:20:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 10:20:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.946.1486912808163@Atlassian.JIRA>


     [ 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.Beta1
                       (was: 3.0.0.Alpha25)


> 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.Beta1
>
>
> 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  Sun Feb 12 12:18:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 12 Feb 2017 12:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8088) Statistics Resources are
 being created without a corresponding ManagementResourceRegistration
In-Reply-To: <JIRA.12676132.1486919839000@Atlassian.JIRA>
References: <JIRA.12676132.1486919839000@Atlassian.JIRA>
	<JIRA.12676132.1486919839807@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676132.1486919839000.1020.1486919880508@Atlassian.JIRA>

Brian Stansberry created WFLY-8088:
--------------------------------------

             Summary: Statistics Resources are being created without a corresponding ManagementResourceRegistration
                 Key: WFLY-8088
                 URL: https://issues.jboss.org/browse/WFLY-8088
             Project: WildFly
          Issue Type: Bug
          Components: JCA, JMS
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.

I found there were no MRRs for

/profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
/profile=*/subsystem=datasources/data-source=*/statistics=jdbc
/profile=*/subsystem=datasources/data-source=*/statistics=pool

I expect the latter two would be repeated for xa-data-source=*

Probably the lack of MRR is correct and the problem is the existence of the resource. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 14:25:00 2017
From: issues at jboss.org (Yeray Borges Santana (JIRA))
Date: Sun, 12 Feb 2017 14:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2066) Kill and destroy operations
 on the server-group
In-Reply-To: <JIRA.12664580.1480526308000@Atlassian.JIRA>
References: <JIRA.12664580.1480526308000@Atlassian.JIRA>
	<JIRA.12664580.1480526308000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664580.1480526308000.1040.1486927500195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges Santana reassigned WFCORE-2066:
--------------------------------------------

    Assignee: Yeray Borges Santana


> 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
>
> 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  Sun Feb 12 14:56:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 12 Feb 2017 14:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.1084.1486929360211@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362264#comment-13362264 ] 

Edson Tirelli commented on DROOLS-1432:
---------------------------------------

Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 14:56:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 12 Feb 2017 14:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.1087.1486929360304@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362264#comment-13362264 ] 

Edson Tirelli edited comment on DROOLS-1432 at 2/12/17 2:55 PM:
----------------------------------------------------------------

Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}{{DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}}}
{quote}


was (Author: tirelli):
Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 14:57:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 12 Feb 2017 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.1090.1486929420139@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362264#comment-13362264 ] 

Edson Tirelli edited comment on DROOLS-1432 at 2/12/17 2:56 PM:
----------------------------------------------------------------

Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}


was (Author: tirelli):
Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}{{DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}}}
{quote}

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 14:58:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 12 Feb 2017 14:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.1093.1486929480147@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362264#comment-13362264 ] 

Edson Tirelli edited comment on DROOLS-1432 at 2/12/17 2:57 PM:
----------------------------------------------------------------

Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''\}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}


was (Author: tirelli):
Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 14:59:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 12 Feb 2017 14:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.1096.1486929540178@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362264#comment-13362264 ] 

Edson Tirelli edited comment on DROOLS-1432 at 2/12/17 2:58 PM:
----------------------------------------------------------------

Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''\}

DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''\}

DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''\}

DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''\}

DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''\}

DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''\}
{quote}


was (Author: tirelli):
Work in progress on this PR:

https://github.com/droolsjbpm/kie-dmn/pull/35

The engine is now reporting FEEL compilation errors, like unknown variables and syntax errors. The example from the test case in the PR, generates the following error messages:

* In the input clause, the string "None" is missing the double quotes, making the engine interpret it as a variable that does not exist:

bq. Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'

* Same problem with the string "3rd Party", that without quotes is not a valid FEEL syntax, resulting in the following error:

bq. Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax

* Here is similar error on the rule itself. The message points to the offending rule and the DMNMessage object contains the ID of the actual element:

bq. Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'

Here is the "toString()" of all the error messages generated from that example:

{quote}DMNMessage\{ severity=ERROR, message='Error compiling FEEL expression '"Gold","Silver",None' on decision table 'Car Damage Responsibility', input clause #1: Unknown variable 'None'', sourceId='_46431f75-29fd-4562-8110-63f571b591b0', exception='', feelEvent=''\}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Driver,3rd Party' on decision table 'Car Damage Responsibility', input clause #2: invalid syntax', sourceId='_b7372019-823a-4b8c-bce4-36ef71184397', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input ',''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Gold' on decision table 'Car Damage Responsibility', rule #1: Unknown variable 'Gold'', sourceId='_7844015a-db0f-4c84-b80d-a6467dd16b6e', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Silver' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Silver'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression '3rd Party' on decision table 'Car Damage Responsibility', rule #2: invalid syntax', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent='SyntaxErrorEvent : no viable alternative at input '[3rd''}
DMNMessage{ severity=ERROR, message='Error compiling FEEL expression 'Tires' on decision table 'Car Damage Responsibility', rule #2: Unknown variable 'Tires'', sourceId='_a5653c63-bbae-47f5-b80c-34f2efbca467', exception='', feelEvent=''}
{quote}

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 15:03:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 12 Feb 2017 15:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2291) Add a dependency from
 org.wildfly.security.elytron-private to org.jboss.logmanager
In-Reply-To: <JIRA.12676133.1486929720000@Atlassian.JIRA>
References: <JIRA.12676133.1486929720000@Atlassian.JIRA>
	<JIRA.12676133.1486929720374@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676133.1486929720000.1099.1486929780170@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2291:
----------------------------------------

             Summary: Add a dependency from org.wildfly.security.elytron-private to org.jboss.logmanager
                 Key: WFCORE-2291
                 URL: https://issues.jboss.org/browse/WFCORE-2291
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta1






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 12 19:25:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Sun, 12 Feb 2017 19:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8007) Replace WorkManager
 elytron-enabled atttribute by elytron-security-domain
In-Reply-To: <JIRA.12674108.1485947862000@Atlassian.JIRA>
References: <JIRA.12674108.1485947862000@Atlassian.JIRA>
	<JIRA.12674108.1485947862000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674108.1485947862000.1141.1486945500247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned WFLY-8007:
------------------------------------

    Assignee: Stefan Guilhen  (was: James Perkins)


Stefan Guilhen has volunteered to work on this.

> Replace WorkManager elytron-enabled atttribute by elytron-security-domain
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8007
>                 URL: https://issues.jboss.org/browse/WFLY-8007
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Stefan Guilhen
>
> Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 00:49:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 00:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8089) Enable
 DatasourcesSubsystemTestCase.testElytronConfig()
In-Reply-To: <JIRA.12676144.1486964882000@Atlassian.JIRA>
References: <JIRA.12676144.1486964882000@Atlassian.JIRA>
	<JIRA.12676144.1486964882461@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676144.1486964882000.1302.1486964940109@Atlassian.JIRA>

Flavia Rainone created WFLY-8089:
------------------------------------

             Summary: Enable DatasourcesSubsystemTestCase.testElytronConfig()
                 Key: WFLY-8089
                 URL: https://issues.jboss.org/browse/WFLY-8089
             Project: WildFly
          Issue Type: Bug
            Reporter: Flavia Rainone
            Assignee: Jason Greene


Fix the test, that checks if transformation of a datasources subsystem XML works with elytron enabled metadata.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 00:57:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 00:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8089) Enable
 DatasourcesSubsystemTestCase.testElytronConfig()
In-Reply-To: <JIRA.12676144.1486964882000@Atlassian.JIRA>
References: <JIRA.12676144.1486964882000@Atlassian.JIRA>
	<JIRA.12676144.1486964882000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676144.1486964882000.1304.1486965420119@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone reassigned WFLY-8089:
------------------------------------

    Assignee: Flavia Rainone  (was: Jason Greene)


> Enable DatasourcesSubsystemTestCase.testElytronConfig()
> -------------------------------------------------------
>
>                 Key: WFLY-8089
>                 URL: https://issues.jboss.org/browse/WFLY-8089
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> Fix the test, that checks if transformation of a datasources subsystem XML works with elytron enabled metadata.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 01:13:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 13 Feb 2017 01:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8090) Changing Elytron
 default-authentication-context requires server restart
In-Reply-To: <JIRA.12676146.1486966368000@Atlassian.JIRA>
References: <JIRA.12676146.1486966368000@Atlassian.JIRA>
	<JIRA.12676146.1486966368351@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676146.1486966368000.1330.1486966381399@Atlassian.JIRA>

Ondrej Lukas created WFLY-8090:
----------------------------------

             Summary: Changing Elytron default-authentication-context requires server restart
                 Key: WFLY-8090
                 URL: https://issues.jboss.org/browse/WFLY-8090
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical
         Attachments: AuthnContextApp.war

In case when Elytron subsystem attribute default-authentication-context is changed (through write-attribute or undefine-attribute operation) then operation succeed and server is NOT set to reload-required state. However changed value is not used until server is reload.

Before fixing, it must be decided whether change of default-authentication-context should require server reload or not. [~dlofthouse] What should be correct behavior?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 01:13:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 13 Feb 2017 01:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8090) Changing Elytron
 default-authentication-context requires server restart
In-Reply-To: <JIRA.12676146.1486966368000@Atlassian.JIRA>
References: <JIRA.12676146.1486966368000@Atlassian.JIRA>
	<JIRA.12676146.1486966368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676146.1486966368000.1339.1486966381587@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8090:
-------------------------------
    Attachment: AuthnContextApp.war


> Changing Elytron default-authentication-context requires server restart
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8090
>                 URL: https://issues.jboss.org/browse/WFLY-8090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>         Attachments: AuthnContextApp.war
>
>
> In case when Elytron subsystem attribute default-authentication-context is changed (through write-attribute or undefine-attribute operation) then operation succeed and server is NOT set to reload-required state. However changed value is not used until server is reload.
> Before fixing, it must be decided whether change of default-authentication-context should require server reload or not. [~dlofthouse] What should be correct behavior?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 01:27:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 01:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8091) Remote alternatives from
 Elytron Enabled attribute at DataSources subsystem
In-Reply-To: <JIRA.12676147.1486967200000@Atlassian.JIRA>
References: <JIRA.12676147.1486967200000@Atlassian.JIRA>
	<JIRA.12676147.1486967200693@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676147.1486967200000.1343.1486967220095@Atlassian.JIRA>

Flavia Rainone created WFLY-8091:
------------------------------------

             Summary: Remote alternatives from Elytron Enabled attribute at DataSources subsystem
                 Key: WFLY-8091
                 URL: https://issues.jboss.org/browse/WFLY-8091
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


If elytron-enabled is set to false,we cannot use the other alternatives:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
jndi-name="java:/H2XADS",user-name=sa,password=sa)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)

The last command fails with:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" =>
"WFLYCTL0105: user-name is invalid in combination with
elytron-enabled"},
    "rolled-back" => true
}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 01:27:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 01:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8091) Remove alternatives from
 Elytron Enabled attribute at DataSources subsystem
In-Reply-To: <JIRA.12676147.1486967201000@Atlassian.JIRA>
References: <JIRA.12676147.1486967201000@Atlassian.JIRA>
	<JIRA.12676147.1486967201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676147.1486967201000.1345.1486967220190@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8091:
---------------------------------
    Summary: Remove alternatives from Elytron Enabled attribute at DataSources subsystem  (was: Remote alternatives from Elytron Enabled attribute at DataSources subsystem)


> Remove alternatives from Elytron Enabled attribute at DataSources subsystem
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-8091
>                 URL: https://issues.jboss.org/browse/WFLY-8091
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> If elytron-enabled is set to false,we cannot use the other alternatives:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
> jndi-name="java:/H2XADS",user-name=sa,password=sa)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> The last command fails with:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" =>
> "WFLYCTL0105: user-name is invalid in combination with
> elytron-enabled"},
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 02:04:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 02:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8091) Remove alternatives from
 Elytron Enabled attributes at DataSources subsystem
In-Reply-To: <JIRA.12676147.1486967201000@Atlassian.JIRA>
References: <JIRA.12676147.1486967201000@Atlassian.JIRA>
	<JIRA.12676147.1486967201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676147.1486967201000.1408.1486969440068@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8091:
---------------------------------
    Summary: Remove alternatives from Elytron Enabled attributes at DataSources subsystem  (was: Remove alternatives from Elytron Enabled attribute at DataSources subsystem)


> Remove alternatives from Elytron Enabled attributes at DataSources subsystem
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8091
>                 URL: https://issues.jboss.org/browse/WFLY-8091
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> If elytron-enabled is set to false,we cannot use the other alternatives:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
> jndi-name="java:/H2XADS",user-name=sa,password=sa)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> The last command fails with:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" =>
> "WFLYCTL0105: user-name is invalid in combination with
> elytron-enabled"},
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 02:10:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 02:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8092) Remove alternatives from
 Elytron Enabled attribute at ResourceAdapters subsystem
In-Reply-To: <JIRA.12676148.1486969746000@Atlassian.JIRA>
References: <JIRA.12676148.1486969746000@Atlassian.JIRA>
	<JIRA.12676148.1486969746741@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676148.1486969746000.1410.1486969800070@Atlassian.JIRA>

Flavia Rainone created WFLY-8092:
------------------------------------

             Summary: Remove alternatives from Elytron Enabled attribute at ResourceAdapters subsystem
                 Key: WFLY-8092
                 URL: https://issues.jboss.org/browse/WFLY-8092
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.

The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 02:14:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 02:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8089) Enable
 DatasourcesSubsystemTestCase.testElytronConfig()
In-Reply-To: <JIRA.12676144.1486964882000@Atlassian.JIRA>
References: <JIRA.12676144.1486964882000@Atlassian.JIRA>
	<JIRA.12676144.1486964882000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676144.1486964882000.1424.1486970040052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8089:
---------------------------------
    Component/s: JCA


> Enable DatasourcesSubsystemTestCase.testElytronConfig()
> -------------------------------------------------------
>
>                 Key: WFLY-8089
>                 URL: https://issues.jboss.org/browse/WFLY-8089
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> Fix the test, that checks if transformation of a datasources subsystem XML works with elytron enabled metadata.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 03:45:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 13 Feb 2017 03:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5879) Some multinode tests fail
 with security manager
In-Reply-To: <JIRA.12597217.1450441124000@Atlassian.JIRA>
References: <JIRA.12597217.1450441124000@Atlassian.JIRA>
	<JIRA.12597217.1450441124000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12597217.1450441124000.1725.1486975501747@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362324#comment-13362324 ] 

Jan Tymel commented on WFLY-5879:
---------------------------------

Hey [~iweiss], the current state is following:
* org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase passes without any issues
* org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase *fails* with security manager
* org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase passes without any issues
* org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase passes without any issues
* org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase *fails* with security manager

It is possible to run {{DynamicJNDIContextEJBInvocationTestCase}} by adding the {{-Dwildfly.tmp.enable.invocation.tests}} attribute (see https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/shared/util/DisableInvocationTestUtil.java ), then it fails with:
{code}
SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:239)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation(DynamicJNDIContextEJBInvocationTestCase.java:95)
	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:275)
	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.IllegalStateException: WFLYEE0046: Failed to instantiate component view
	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
	... 154 more
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.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:152)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:77)
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:147)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:77)
	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:137)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:77)
	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:88)
	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
	... 157 more
Caused by: javax.ejb.EJBException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/tmp/aaa-inguv-dotaz/jboss-eap7/dist/target/jboss-eap-7.1/modules/system/layers/base/org/wildfly/naming-client/main/wildfly-naming-client-1.0.0.Beta10.jar" "read")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dynamic-jndi-context-ejb-invocation-test.jar" from Service Module Loader")
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInNoTx(CMTTxInterceptor.java:213)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:265)
	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:87)
	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
	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)
	... 173 more
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/tmp/aaa-inguv-dotaz/jboss-eap7/dist/target/jboss-eap-7.1/modules/system/layers/base/org/wildfly/naming-client/main/wildfly-naming-client-1.0.0.Beta10.jar" "read")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dynamic-jndi-context-ejb-invocation-test.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.SecurityManager.checkRead(SecurityManager.java:888)
	at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:350)
	at java.util.zip.ZipFile.<init>(ZipFile.java:210)
	at java.util.zip.ZipFile.<init>(ZipFile.java:149)
	at java.util.jar.JarFile.<init>(JarFile.java:166)
	at java.util.jar.JarFile.<init>(JarFile.java:103)
	at sun.net.www.protocol.jar.URLJarFile.<init>(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 org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:463)
	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:127)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.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.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
	at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:73)
	at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:120)
	at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:106)
	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.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
	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.invokeInNoTx(CMTTxInterceptor.java:263)
	... 188 more
{code}


{{DatabaseTimerServiceMultiNodeTestCase}} fails in QE CI with (not able to reproduce locally yet):
{code}
javax.ejb.EJBException: java.lang.RuntimeException: java.lang.RuntimeException: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/TimeDs
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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 ...asynchronous invocation...(Unknown Source)
	at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
	at com.sun.proxy.$Proxy26.scheduleTimer(Unknown Source)
	at org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase.testEjbTimeoutOnOtherNode(DatabaseTimerServiceMultiNodeTestCase.java:202)
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/TimeDs
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/TimeDs
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:330)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/TimeDs
	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/TimeDs
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:657)
	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:748)
	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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.resource.ResourceException: IJ031084: Unable to create connection
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:345)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:591)
	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:748)
	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.19.64.116:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""ModuleClassLoader for Module ""deployment.testTimerServiceSimple.war"" from Service Module Loader"")" [50000-176]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
	at org.h2.message.DbException.get(DbException.java:167)
	at org.h2.message.DbException.convert(DbException.java:294)
	at org.h2.message.DbException.toSQLException(DbException.java:267)
	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:372)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:121)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:91)
	at org.h2.Driver.connect(Driver.java:74)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:321)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:591)
	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:748)
	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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" "10.19.64.116:9092" "connect,resolve")" in code source "(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.testTimerServiceSimple.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.SecurityManager.checkConnect(SecurityManager.java:1051)
	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
	at java.net.Socket.connect(Socket.java:584)
	at org.h2.util.NetUtils.createSocket(NetUtils.java:123)
	at org.h2.util.NetUtils.createSocket(NetUtils.java:103)
	at org.h2.engine.SessionRemote.initTransfer(SessionRemote.java:100)
	at org.h2.engine.SessionRemote.connectServer(SessionRemote.java:430)
	at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:311)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:107)
	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:91)
	at org.h2.Driver.connect(Driver.java:74)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:321)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:352)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:287)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1320)
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:699)
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:598)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:591)
	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:748)
	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:64)
	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:481)
	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:307)
	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	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:57)
	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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:212)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:77)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:158)
	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
	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}

> Some multinode tests fail with security manager
> -----------------------------------------------
>
>                 Key: WFLY-5879
>                 URL: https://issues.jboss.org/browse/WFLY-5879
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Test Suite
>            Reporter: Ondrej Kotek
>            Assignee: Ingo Weiss
>             Fix For: 10.2.0.Final
>
>
> *org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase}}
> fails with:
> {noformat}
> javax.naming.NamingException: Failed to create proxy
> 	at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:873)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:222)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:230)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.getStatefulRemote(ClientEjb.java:60)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb.testSameTransactionEachCall(ClientEjb.java:77)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> 	at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	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.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 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: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.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.as.test.multinode.transaction.ClientEjb$$$view1.testSameTransactionEachCall(Unknown Source)
> 	at org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSameTransactionEachCall(TransactionInvocationTestCase.java:97)
> {noformat}
> *org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase}}
> fails with:
> {noformat}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-2) Failed: org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances: javax.naming.NameNotFoundException: StatefulBeanA!org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> 	at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> 	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.doLookup(InitialContext.java:290)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances(DynamicJNDIContextEJBInvocationTestCase.java:116)
> 	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.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:497)
> 	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:497)
> 	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.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor22.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor17.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor16.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:247)
> 	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:223)
> 	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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> 	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:92)
> 	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)
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> 	at org.jboss.as.naming.ServiceBasedNamingStore$1.run(ServiceBasedNamingStore.java:138)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:135)
> 	... 145 more
> 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.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.distributable.DistributableCache.create(DistributableCache.java:94)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:56)
> 	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$DefaultViewInstanceFactory.createViewInstance(ViewService.java:302)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> 	at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> 	at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> 	... 148 more
> Caused by: javax.naming.NamingException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null") [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" of "null")]
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:137)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.scoped.context.StatefulBeanA.onConstruct(StatefulBeanA.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:497)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:117)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBCreateInterceptor.processInvocation(SFSBCreateInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	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.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	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.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	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 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:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	... 164 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "createEJBClientContext")" in code source "(vfs:/content/dynamic-jndi-context-ejb-invocation-test.jar <no signer certificates>)" 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.ejb.client.EJBClientContext.create(EJBClientContext.java:198)
> 	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:90)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:256)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
> 	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:133)
> 	... 223 more
> {noformat}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> fails with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-2-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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 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: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.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy62.remoteCall(Unknown Source)
> 	at org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote(RemoteLocalCallProfileTestCase.java:185)
> 	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.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:497)
> 	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:497)
> 	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.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:497)
> 	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.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	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:247)
> 	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:223)
> 	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 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:497)
> 	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:92)
> 	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)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.marshalling.reflect.SerializableClassRegistry.lookup(SerializableClassRegistry.java:70)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:916)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> 	at org.jboss.ejb.client.remoting.SessionOpenResponseHandler$SessionIDResultProducer.getResult(SessionOpenResponseHandler.java:94)
> 	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:454)
> 	at org.jboss.ejb.client.EJBClient.createSessionWithPossibleRetries(EJBClient.java:225)
> 	at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:202)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:227)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:204)
> 	... 226 more
> {code}
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote*
> *org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase#testStatelessRemoteFromRemote}}
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.remotecall.RemoteLocalCallTestCase#testStatelessRemoteFromRemote}}
> Fail with:
> {code}
> SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.multinode.remotecall.RemoteLocalCallProfileTestCase.testStatelessRemoteFromRemote: javax.naming.NamingException: Failed to create proxy [Root exception is java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/remotelocalcall-test-client.jar <no signer certificates>)" of "null")]
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:206)
> 	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:187)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.jboss.as.test.multinode.remotecall.StatefulBean.remoteCall(StatefulBean.java:82)
> 	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.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	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:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	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:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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 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: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.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:259)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:138)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> 	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> 	at com.sun.proxy.$Proxy65.remoteCall(Unknown Source)
> 	at 
> {code}
> *org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.multinode -Dts.noSmoke -Dtest=org.jboss.as.test.multinode.ejb.timer.database.DatabaseTimerServiceMultiNodeTestCase#testEjbTimeoutOnOtherNode}}
> Fails with:
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.security.AccessControlException: WFSM000001: Permission check failed (permission ""(""java.net.SocketPermission"" ""10.16.91.218:9092"" ""connect,resolve"")"" in code source ""(vfs:/content/testTimerServiceSimple.war/WEB-INF/classes <no signer certificates>)"" of ""null"")" [50000-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:160)
> 	at org.h2.message.DbException.convert(DbException.java:283)
> 	at org.h2.message.DbException.toSQLException(DbException.java:256)
> 	at org.h2.message.TraceObject.logAndConvert(TraceObject.java:368)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:119)
> 	at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:90)
> 	at org.h2.Driver.connect(Driver.java:73)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:350)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:285)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1319)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:496)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:708)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:607)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590)
> 	at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747)
> 	at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> 	at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> 	at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:325)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:614)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createTimer(TimerServiceImpl.java:482)
> 	at org.jboss.as.ejb3.timerservice.TimerServiceImpl.createSingleActionTimer(TimerServiceImpl.java:308)
> 	at org.jboss.as.test.multinode.ejb.timer.database.TimedObjectTimerServiceBean.scheduleTimer(TimedObjectTimerServiceBean.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:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at 
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 05:55:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 13 Feb 2017 05:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1437) Avoid stax-utils dependency
 by manual indentation
In-Reply-To: <JIRA.12676214.1486983275000@Atlassian.JIRA>
References: <JIRA.12676214.1486983275000@Atlassian.JIRA>
	<JIRA.12676214.1486983275437@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676214.1486983275000.2632.1486983300481@Atlassian.JIRA>

Matteo Mortari created DROOLS-1437:
--------------------------------------

             Summary: Avoid stax-utils dependency by manual indentation
                 Key: DROOLS-1437
                 URL: https://issues.jboss.org/browse/DROOLS-1437
             Project: Drools
          Issue Type: Enhancement
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


Avoid the stax-utils dependency:

{code:xml}
<dependency>
      <groupId>net.java.dev.stax-utils</groupId>
      <artifactId>stax-utils</artifactId>
      <exclusions>
        <exclusion>
        <groupId>com.bea.xml</groupId>
        <artifactId>jsr173-ri</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
{code}

by implementing manually indentation during serialization.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 06:18:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 13 Feb 2017 06:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8093) Coverity static analysis,
 dereference after null check, KeyStoreCredentialStore (Elytron)
In-Reply-To: <JIRA.12676221.1486984622000@Atlassian.JIRA>
References: <JIRA.12676221.1486984622000@Atlassian.JIRA>
	<JIRA.12676221.1486984622610@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676221.1486984622000.2909.1486984680370@Atlassian.JIRA>

Martin Choma created WFLY-8093:
----------------------------------

             Summary: Coverity static analysis, dereference after null check, KeyStoreCredentialStore (Elytron)
                 Key: WFLY-8093
                 URL: https://issues.jboss.org/browse/WFLY-8093
             Project: WildFly
          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  Mon Feb 13 07:17:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 13 Feb 2017 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8068) Credential-store attribute
 relative-to doesn't reference path as required
In-Reply-To: <JIRA.12675844.1486669361000@Atlassian.JIRA>
References: <JIRA.12675844.1486669361000@Atlassian.JIRA>
	<JIRA.12675844.1486669361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675844.1486669361000.3355.1486988220569@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8068:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Credential-store attribute relative-to doesn't reference path as required
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8068
>                 URL: https://issues.jboss.org/browse/WFLY-8068
>             Project: WildFly
>          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  Mon Feb 13 07:36:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_Saka=C5=99_=28JIRA=29?=)
Date: Mon, 13 Feb 2017 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7038) License files issues
In-Reply-To: <JIRA.12648590.1473062737000@Atlassian.JIRA>
References: <JIRA.12648590.1473062737000@Atlassian.JIRA>
	<JIRA.12648590.1473062737000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648590.1473062737000.3466.1486989360242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Saka? reopened WFLY-7038:
------------------------------


license for org.glassfish:javax.json should be CDDL 1.1 + GPL 2.0+CE

> License files issues
> --------------------
>
>                 Key: WFLY-7038
>                 URL: https://issues.jboss.org/browse/WFLY-7038
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.1.0.Final
>            Reporter: Petr Saka?
>            Assignee: Petr Saka?
>             Fix For: 11.0.0.Alpha1
>
>
> Various problems with licenses were found.
> - bsd.txt file contains BSD license template
> - some licenses are incorrect



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 07:37:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_Saka=C5=99_=28JIRA=29?=)
Date: Mon, 13 Feb 2017 07:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7038) License files issues
In-Reply-To: <JIRA.12648590.1473062737000@Atlassian.JIRA>
References: <JIRA.12648590.1473062737000@Atlassian.JIRA>
	<JIRA.12648590.1473062737000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648590.1473062737000.3473.1486989420077@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362507#comment-13362507 ] 

Petr Saka? edited comment on WFLY-7038 at 2/13/17 7:36 AM:
-----------------------------------------------------------

license for org.glassfish:javax.json should be CDDL 1.1 + GPL 2.0+CE
https://glassfish.java.net/public/CDDL+GPL_1_1.html


was (Author: psakar):
license for org.glassfish:javax.json should be CDDL 1.1 + GPL 2.0+CE

> License files issues
> --------------------
>
>                 Key: WFLY-7038
>                 URL: https://issues.jboss.org/browse/WFLY-7038
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 10.1.0.Final
>            Reporter: Petr Saka?
>            Assignee: Petr Saka?
>             Fix For: 11.0.0.Alpha1
>
>
> Various problems with licenses were found.
> - bsd.txt file contains BSD license template
> - some licenses are incorrect



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 07:39:02 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 13 Feb 2017 07:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8094) Coverity static analysis,
 Resource leak, LdapsecurityRealm (Elytron)
In-Reply-To: <JIRA.12676243.1486989526000@Atlassian.JIRA>
References: <JIRA.12676243.1486989526000@Atlassian.JIRA>
	<JIRA.12676243.1486989526445@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676243.1486989526000.3518.1486989542323@Atlassian.JIRA>

Martin Choma created WFLY-8094:
----------------------------------

             Summary: Coverity static analysis, Resource leak, LdapsecurityRealm (Elytron)
                 Key: WFLY-8094
                 URL: https://issues.jboss.org/browse/WFLY-8094
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Coverity static analysis found 8 occurence of Closeable object LdapIdentity not closing properly. 

https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359307&mergedDefectId=1400389
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359304&mergedDefectId=1400388
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359309&mergedDefectId=1400387
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359306&mergedDefectId=1400386
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359311&mergedDefectId=1400385
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359312&mergedDefectId=1400384
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359313&mergedDefectId=1400383
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359303&mergedDefectId=1400382

{{LdapIdentity}} in {{close()}} method just close provided dirContext. {{LdapIdentity}} does not create dirContext by itself. So it looks to me it is no necessary to implement Closeable in {{LdapIdentity}}, as code where dirContext was created should be responsible for closing it (and according to coverity it is closed properly everywhere).

{code:java|title=LdapSecurityRealm.java}
        private class LdapIdentity implements Closeable {

            private final String name;
            private final DirContext dirContext;
            private final String distinguishedName;
            private final SearchResult entry;

            LdapIdentity(String name, DirContext dirContext, String distinguishedName, SearchResult entry) {
                this.name = name;
                this.dirContext = dirContext;
                this.distinguishedName = distinguishedName;
                this.entry = entry;
            }

            String getName() {
                return this.name;
            }

            DirContext getDirContext() {
                return this.dirContext;
            }

            String getDistinguishedName() {
                return this.distinguishedName;
            }

            SearchResult getEntry() {
                return this.entry;
            }

            @Override
            public void close() throws IOException {
                try {
                    dirContext.close();
                } catch (NamingException e) {
                    log.debug("LdapSecurityRealm failed to close DirContext", e);
                }
            }
        }
{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 07:57:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 13 Feb 2017 07:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8095) Coverity static analysis,
 Dereference null return value, OAuth2CredentialSource (Elytron)
In-Reply-To: <JIRA.12676249.1486990585000@Atlassian.JIRA>
References: <JIRA.12676249.1486990585000@Atlassian.JIRA>
	<JIRA.12676249.1486990585873@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676249.1486990585000.3617.1486990621460@Atlassian.JIRA>

Martin Choma created WFLY-8095:
----------------------------------

             Summary: Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
                 Key: WFLY-8095
                 URL: https://issues.jboss.org/browse/WFLY-8095
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


Coverity found possible dereferencing of null value returned from {{resolveSSLContext()}} in {{openConnection()}}

https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564099&defectInstanceId=2359300&mergedDefectId=1389514

{code:java|title=OAuth2CredentialSource.java}
    private SSLContext resolveSSLContext() {
        if (!isHttps(tokenEndpointUri)) {
            return null;
        }
        return sslContextSupplier == null ? null : sslContextSupplier.get();
    }

    private HttpURLConnection openConnection() throws IOException {
        log.debugf("Opening connection to [%s]", tokenEndpointUri);
        HttpURLConnection connection = (HttpURLConnection) tokenEndpointUri.openConnection();

        if (isHttps(tokenEndpointUri)) {
            HttpsURLConnection https = (HttpsURLConnection) connection;

            https.setSSLSocketFactory(resolveSSLContext().getSocketFactory());
            if (hostnameVerifierSupplier != null) {
                https.setHostnameVerifier(checkNotNullParam("hostnameVerifier", hostnameVerifierSupplier.get()));
            }
        }

        return connection;
    }
{code}


NPE could probably happen if {{oauth2-introspection}} is configured with no {{client-ssl-context}} and https {{introspection-url}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 08:55:00 2017
From: issues at jboss.org (=?UTF-8?Q?Nikoleta_=C5=BDiakov=C3=A1_=28JIRA=29?=)
Date: Mon, 13 Feb 2017 08:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8096) Outdated license file in
	infinispan JARs
In-Reply-To: <JIRA.12676261.1486993894000@Atlassian.JIRA>
References: <JIRA.12676261.1486993894000@Atlassian.JIRA>
	<JIRA.12676261.1486993894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676261.1486993894000.4005.1486994100322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikoleta ?iakov? moved JBEAP-8798 to WFLY-8096:
-----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8096  (was: JBEAP-8798)
             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.DR11)


> Outdated license file in infinispan JARs
> ----------------------------------------
>
>                 Key: WFLY-8096
>                 URL: https://issues.jboss.org/browse/WFLY-8096
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Nikoleta ?iakov?
>            Assignee: Paul Ferraro
>
> Infinispan JARs in EAP distribution contain LICENSE.txt file with LGPL 2.1. However, the correct license in version 8.2.5.Final is ASL 2.0 as stated in https://github.com/infinispan/infinispan/blob/8.2.5.Final/README.md and https://github.com/infinispan/infinispan/blob/8.2.5.Final/license/src/main/resources/META-INF/LICENSE.txt.vm
> The Infinispan license changed in version 6.0.0 (ISPN-3292).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 09:09:01 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 09:09:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8092) Fix Elytron Enabled attribute
 at ResourceAdapters subsystem
In-Reply-To: <JIRA.12676148.1486969747000@Atlassian.JIRA>
References: <JIRA.12676148.1486969747000@Atlassian.JIRA>
	<JIRA.12676148.1486969747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676148.1486969747000.4509.1486994941316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8092:
---------------------------------
    Summary: Fix Elytron Enabled attribute at ResourceAdapters subsystem  (was: Remove alternatives from Elytron Enabled attribute at ResourceAdapters subsystem)


> Fix Elytron Enabled attribute at ResourceAdapters subsystem
> -----------------------------------------------------------
>
>                 Key: WFLY-8092
>                 URL: https://issues.jboss.org/browse/WFLY-8092
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:11:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8092) Fix Elytron Enabled attribute
 at ResourceAdapters subsystem
In-Reply-To: <JIRA.12676148.1486969747000@Atlassian.JIRA>
References: <JIRA.12676148.1486969747000@Atlassian.JIRA>
	<JIRA.12676148.1486969747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676148.1486969747000.4541.1486995060943@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8092:
---------------------------------
    Description: 
This Jira is for all ELYTRON_ENABLED attributes defined in resource adapters subsystem.
The attribute definition has two bugs: 
- alternatives defined:
The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.

The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.
- marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a  <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now



  was:
The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.

The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.



> Fix Elytron Enabled attribute at ResourceAdapters subsystem
> -----------------------------------------------------------
>
>                 Key: WFLY-8092
>                 URL: https://issues.jboss.org/browse/WFLY-8092
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This Jira is for all ELYTRON_ENABLED attributes defined in resource adapters subsystem.
> The attribute definition has two bugs: 
> - alternatives defined:
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.
> - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a  <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:11:01 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 09:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8092) Fix Elytron Enabled
 attributes at ResourceAdapters subsystem
In-Reply-To: <JIRA.12676148.1486969747000@Atlassian.JIRA>
References: <JIRA.12676148.1486969747000@Atlassian.JIRA>
	<JIRA.12676148.1486969747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676148.1486969747000.4544.1486995061010@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8092:
---------------------------------
    Summary: Fix Elytron Enabled attributes at ResourceAdapters subsystem  (was: Fix Elytron Enabled attribute at ResourceAdapters subsystem)


> Fix Elytron Enabled attributes at ResourceAdapters subsystem
> ------------------------------------------------------------
>
>                 Key: WFLY-8092
>                 URL: https://issues.jboss.org/browse/WFLY-8092
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This Jira is for all ELYTRON_ENABLED attributes defined in resource adapters subsystem.
> The attribute definition has two bugs: 
> - alternatives defined:
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.
> - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a  <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:12:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8091) Fix Elytron Enabled
 attributes at DataSources subsystem
In-Reply-To: <JIRA.12676147.1486967201000@Atlassian.JIRA>
References: <JIRA.12676147.1486967201000@Atlassian.JIRA>
	<JIRA.12676147.1486967201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676147.1486967201000.4547.1486995120245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8091:
---------------------------------
    Summary: Fix Elytron Enabled attributes at DataSources subsystem  (was: Remove alternatives from Elytron Enabled attributes at DataSources subsystem)


> Fix Elytron Enabled attributes at DataSources subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-8091
>                 URL: https://issues.jboss.org/browse/WFLY-8091
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> If elytron-enabled is set to false,we cannot use the other alternatives:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
> jndi-name="java:/H2XADS",user-name=sa,password=sa)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> The last command fails with:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" =>
> "WFLYCTL0105: user-name is invalid in combination with
> elytron-enabled"},
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:13:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Mon, 13 Feb 2017 09:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8091) Fix Elytron Enabled
 attributes at DataSources subsystem
In-Reply-To: <JIRA.12676147.1486967201000@Atlassian.JIRA>
References: <JIRA.12676147.1486967201000@Atlassian.JIRA>
	<JIRA.12676147.1486967201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676147.1486967201000.4559.1486995180995@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated WFLY-8091:
---------------------------------
    Description: 
This Jira is for all ELYTRON_ENABLED attributes defined in datasources subsystem.
The attribute definition has two bugs: 
- alternatives defined:
The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid. (see more details below)

The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at AbstractDataSourceAdd/XaDataSourceAdd.

- marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now

More details on the alternatives bug:

If elytron-enabled is set to false,we cannot use the other alternatives:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
jndi-name="java:/H2XADS",user-name=sa,password=sa)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)

The last command fails with:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" =>
"WFLYCTL0105: user-name is invalid in combination with
elytron-enabled"},
    "rolled-back" => true
}

  was:
If elytron-enabled is set to false,we cannot use the other alternatives:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
jndi-name="java:/H2XADS",user-name=sa,password=sa)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)

The last command fails with:

/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" =>
"WFLYCTL0105: user-name is invalid in combination with
elytron-enabled"},
    "rolled-back" => true
}



> Fix Elytron Enabled attributes at DataSources subsystem
> -------------------------------------------------------
>
>                 Key: WFLY-8091
>                 URL: https://issues.jboss.org/browse/WFLY-8091
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> This Jira is for all ELYTRON_ENABLED attributes defined in datasources subsystem.
> The attribute definition has two bugs: 
> - alternatives defined:
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid. (see more details below)
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at AbstractDataSourceAdd/XaDataSourceAdd.
> - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now
> More details on the alternatives bug:
> If elytron-enabled is set to false,we cannot use the other alternatives:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
> jndi-name="java:/H2XADS",user-name=sa,password=sa)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> The last command fails with:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" =>
> "WFLYCTL0105: user-name is invalid in combination with
> elytron-enabled"},
>     "rolled-back" => true
> }



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:14:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 13 Feb 2017 09:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8097) Coverity static analysis,
 suspicious bitwise logical expression, DigestUtil (Elytron)
In-Reply-To: <JIRA.12676266.1486995214000@Atlassian.JIRA>
References: <JIRA.12676266.1486995214000@Atlassian.JIRA>
	<JIRA.12676266.1486995214730@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676266.1486995214000.4599.1486995240573@Atlassian.JIRA>

Martin Choma created WFLY-8097:
----------------------------------

             Summary: Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
                 Key: WFLY-8097
                 URL: https://issues.jboss.org/browse/WFLY-8097
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9563899&defectInstanceId=2359232&mergedDefectId=1377462

See detailed description of possible problem in [1]

If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails

{code}
        byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
        assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
{code}

If I change decodeByteOrderedInteger implementation according to [1], all tests passes.

{code}
result |= (buf[offset + i] & 0xff);
{code}

[1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE

Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 09:22:00 2017
From: issues at jboss.org (Aaron Ogburn (JIRA))
Date: Mon, 13 Feb 2017 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8098) ajp connection hangs if a
 post HTTP request header contains 'Transfer-Encoding: chunked'
In-Reply-To: <JIRA.12676270.1486995661000@Atlassian.JIRA>
References: <JIRA.12676270.1486995661000@Atlassian.JIRA>
	<JIRA.12676270.1486995661970@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676270.1486995661000.4711.1486995720510@Atlassian.JIRA>

Aaron Ogburn created WFLY-8098:
----------------------------------

             Summary: ajp connection hangs if a post HTTP request header contains  'Transfer-Encoding: chunked'
                 Key: WFLY-8098
                 URL: https://issues.jboss.org/browse/WFLY-8098
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.0.0.Final
         Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
            Reporter: Aaron Ogburn
            Assignee: Stuart Douglas


When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. 

It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.

We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml  and the apache configuration file.






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 10:40:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8099) Define modcluster/ssl vs
 ssl-context priority
In-Reply-To: <JIRA.12676293.1487000317000@Atlassian.JIRA>
References: <JIRA.12676293.1487000317000@Atlassian.JIRA>
	<JIRA.12676293.1487000317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676293.1487000317000.5639.1487000400695@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-8806 to WFLY-8099:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8099  (was: JBEAP-8806)
             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.DR11)


> Define modcluster/ssl vs ssl-context priority
> ---------------------------------------------
>
>                 Key: WFLY-8099
>                 URL: https://issues.jboss.org/browse/WFLY-8099
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> Specify what should be used if both ssl and ssl-context are set in modcluster subsystem.
> There is no warning that both are set, nor error when ssl-context is different
> It looks that ssl-context has priority 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 10:40:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Feb 2017 10:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8099) Define modcluster/ssl vs
 ssl-context priority
In-Reply-To: <JIRA.12676293.1487000317000@Atlassian.JIRA>
References: <JIRA.12676293.1487000317000@Atlassian.JIRA>
	<JIRA.12676293.1487000317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676293.1487000317000.5649.1487000401002@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8099:
---------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Define modcluster/ssl vs ssl-context priority
> ---------------------------------------------
>
>                 Key: WFLY-8099
>                 URL: https://issues.jboss.org/browse/WFLY-8099
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: No Release
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> Specify what should be used if both ssl and ssl-context are set in modcluster subsystem.
> There is no warning that both are set, nor error when ssl-context is different
> It looks that ssl-context has priority 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 10:40:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8099) Define modcluster/ssl vs
 ssl-context priority
In-Reply-To: <JIRA.12676293.1487000317000@Atlassian.JIRA>
References: <JIRA.12676293.1487000317000@Atlassian.JIRA>
	<JIRA.12676293.1487000317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676293.1487000317000.5644.1487000400881@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8099:
---------------------------------
    Affects Version/s: No Release


> Define modcluster/ssl vs ssl-context priority
> ---------------------------------------------
>
>                 Key: WFLY-8099
>                 URL: https://issues.jboss.org/browse/WFLY-8099
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: No Release
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 11.0.0.Alpha1
>
>
> Specify what should be used if both ssl and ssl-context are set in modcluster subsystem.
> There is no warning that both are set, nor error when ssl-context is different
> It looks that ssl-context has priority 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 10:43:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 13 Feb 2017 10:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-915) Elytron filesystem caching
 realm should cache attributes and credentials
In-Reply-To: <JIRA.12674786.1486126284000@Atlassian.JIRA>
References: <JIRA.12674786.1486126284000@Atlassian.JIRA>
	<JIRA.12674786.1486126284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674786.1486126284000.5728.1487000581929@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-915:
------------------------------

    Assignee: Jan Kalina


> Elytron filesystem caching realm should cache attributes and credentials
> ------------------------------------------------------------------------
>
>                 Key: ELY-915
>                 URL: https://issues.jboss.org/browse/ELY-915
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Ondrej Kotek
>            Assignee: Jan Kalina
>
> Elytron caching realm backed by filesystem realm provides caching for identity objects but not for related credentials and attributes.
> Credentials and attributes should not be loaded from file system for a cache hit.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 11:24:00 2017
From: issues at jboss.org (Sanne Grinovero (JIRA))
Date: Mon, 13 Feb 2017 11:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-105) Option to have
 LoggingToolsProcessor to not use javax.annotation.Generated
In-Reply-To: <JIRA.12616537.1461349690000@Atlassian.JIRA>
References: <JIRA.12616537.1461349690000@Atlassian.JIRA>
	<JIRA.12616537.1461349690000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616537.1461349690000.6133.1487003040272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362700#comment-13362700 ] 

Sanne Grinovero commented on LOGTOOL-105:
-----------------------------------------

The plot thickens:
 - http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-February/011322.html

[~jamezp] [~dmlloyd] maybe we should merge this? I understand it's not the only solution - nor probably the best one - but I'd feel better to have a way out, in case of emergency need.

We can take it out later.

> Option to have LoggingToolsProcessor to not use javax.annotation.Generated
> --------------------------------------------------------------------------
>
>                 Key: LOGTOOL-105
>                 URL: https://issues.jboss.org/browse/LOGTOOL-105
>             Project: Log Tool
>          Issue Type: Feature Request
>            Reporter: Sanne Grinovero
>            Assignee: Sanne Grinovero
>             Fix For: 2.1.0.Alpha2
>
>
> To allow projects using the JBoss Logging annotation processor to test latest Java 9 Jigsaw builds, we need to be able to workaround issue
>  https://bugs.openjdk.java.net/browse/JDK-8152842
> I'm introducing an annotation processor option which will cause the generated source code to "forget" to mark the generated code with {{javax.annotation.Generated}}.
> -{{AskipGeneratedAnnotation=true}}
> The JMH annotation processor followed a similar path:
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901643



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 11:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 11:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-944) Support using CallbackHandler
	as last resort
In-Reply-To: <JIRA.12676451.1487004300000@Atlassian.JIRA>
References: <JIRA.12676451.1487004300000@Atlassian.JIRA>
	<JIRA.12676451.1487004300172@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676451.1487004300000.6425.1487004360432@Atlassian.JIRA>

Darran Lofthouse created ELY-944:
------------------------------------

             Summary: Support using CallbackHandler as last resort
                 Key: ELY-944
                 URL: https://issues.jboss.org/browse/ELY-944
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Client
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 1.1.0.Beta26


In many cases where a CallbackHandler is supplied we actually still want credentials already defined on the AuthenticationConfiguration to take priority with the CallbackHandler reserved for user interaction where we do not have a credential.





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 12:01:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 13 Feb 2017 12:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1438) Make property reactivity to
 work even when the property setter is in an inherited class
In-Reply-To: <JIRA.12676455.1487005223000@Atlassian.JIRA>
References: <JIRA.12676455.1487005223000@Atlassian.JIRA>
	<JIRA.12676455.1487005223288@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676455.1487005223000.6532.1487005260234@Atlassian.JIRA>

Mario Fusco created DROOLS-1438:
-----------------------------------

             Summary: Make property reactivity to work even when the property setter is in an inherited class
                 Key: DROOLS-1438
                 URL: https://issues.jboss.org/browse/DROOLS-1438
             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  Mon Feb 13 12:36:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 12:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310427@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.6798.1487007360266@Atlassian.JIRA>

Ken Wills created WFCORE-2292:
---------------------------------

             Summary: HTTPS / Native Management protocol mismatch when using SSL
                 Key: WFCORE-2292
                 URL: https://issues.jboss.org/browse/WFCORE-2292
             Project: WildFly Core
          Issue Type: Bug
          Components: Server
            Reporter: Ken Wills
            Assignee: Ken Wills


It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.

1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
^^^^^^^

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b

This was with native management, but I see the same thing using https.

Relevant config in use:

{quote)
 <management>
  <security-realms>
  <security-realm name="sslSecurityRealm">
    <server-identities>
      <ssl>
        <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
      </ssl>
    </server-identities>
    <authentication>
        <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
    </authentication>
  </security-realm>
 </security-realms>

 <management-interfaces>
   <native-interface security-realm="sslSecurityRealm">
    <socket-binding native="native"/>
    </native-interface>
    </management-interfaces>
 </management>


    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
    </socket-binding-group>





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 12:36:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 12:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.6810.1487007360614@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-2292:
------------------------------
    Description: 
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.

1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
^^^^^^^

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b

This was with native management, but I see the same thing using https.

Relevant bits of config in use:

{quote}
 <management>
  <security-realms>
  <security-realm name="sslSecurityRealm">
    <server-identities>
      <ssl>
        <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
      </ssl>
    </server-identities>
    <authentication>
        <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
    </authentication>
  </security-realm>
 </security-realms>

 <management-interfaces>
   <native-interface security-realm="sslSecurityRealm">
    <socket-binding native="native"/>
    </native-interface>
    </management-interfaces>
 </management>


    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
    </socket-binding-group>
{quote}


  was:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.

1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
^^^^^^^

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b

This was with native management, but I see the same thing using https.

Relevant config in use:

{quote)
 <management>
  <security-realms>
  <security-realm name="sslSecurityRealm">
    <server-identities>
      <ssl>
        <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
      </ssl>
    </server-identities>
    <authentication>
        <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
    </authentication>
  </security-realm>
 </security-realms>

 <management-interfaces>
   <native-interface security-realm="sslSecurityRealm">
    <socket-binding native="native"/>
    </native-interface>
    </management-interfaces>
 </management>


    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
    </socket-binding-group>





> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https.
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 12:39:01 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 12:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.6824.1487007541005@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362753#comment-13362753 ] 

Ken Wills commented on WFCORE-2292:
-----------------------------------

I should not, the default standalone config works fine.

> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https.
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 12:39:01 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 12:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.6826.1487007541087@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362753#comment-13362753 ] 

Ken Wills edited comment on WFCORE-2292 at 2/13/17 12:38 PM:
-------------------------------------------------------------

I should note, the default standalone config works fine.


was (Author: luck3y):
I should not, the default standalone config works fine.

> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https.
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 12:44:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 12:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.6923.1487007840429@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-2292:
------------------------------
    Description: 
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.

1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
^^^^^^^

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b

This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:

./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 

Relevant bits of config in use:

{quote}
 <management>
  <security-realms>
  <security-realm name="sslSecurityRealm">
    <server-identities>
      <ssl>
        <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
      </ssl>
    </server-identities>
    <authentication>
        <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
    </authentication>
  </security-realm>
 </security-realms>

 <management-interfaces>
   <native-interface security-realm="sslSecurityRealm">
    <socket-binding native="native"/>
    </native-interface>
    </management-interfaces>
 </management>


    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
    </socket-binding-group>
{quote}


  was:
It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.

1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
^^^^^^^

11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b

This was with native management, but I see the same thing using https.

Relevant bits of config in use:

{quote}
 <management>
  <security-realms>
  <security-realm name="sslSecurityRealm">
    <server-identities>
      <ssl>
        <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
      </ssl>
    </server-identities>
    <authentication>
        <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
    </authentication>
  </security-realm>
 </security-realms>

 <management-interfaces>
   <native-interface security-realm="sslSecurityRealm">
    <socket-binding native="native"/>
    </native-interface>
    </management-interfaces>
 </management>


    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
        <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
    </socket-binding-group>
{quote}




> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 13:48:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 13:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011625000@Atlassian.JIRA>
References: <JIRA.12676462.1487011625000@Atlassian.JIRA>
	<JIRA.12676462.1487011625781@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011625000.7145.1487011680304@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2293:
----------------------------------------

             Summary: Centrally define sensitivity classifications for references to Elytron capabilities.
                 Key: WFCORE-2293
                 URL: https://issues.jboss.org/browse/WFCORE-2293
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta1


Predominantly the following 6 items are referenced across the application server: -

Authentication Context
Credential Store
HTTP Authentication Factory
SASL Authentication Factory
SSLContext
Security Domain

We should probably represent these as: -

(Authentication Context) -> Client Security Ref
(Credential Store) -> Credential
(HTTP / SASL Authentication Factory) -> Authentication Factory Ref
(Security Domain) -> Security Domain Ref
(SSL Context) -> SSL Ref

We already have 'Credential' defined so we can re-use that.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 13:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 13:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7166.1487012280575@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362783#comment-13362783 ] 

Brian Stansberry commented on WFCORE-2293:
------------------------------------------

[~dlofthouse] By "Credential Store" you're basically talking about credential reference attributes, right? If so, yeah, that's analogous to the existing username/password type attribute where we use SensitivityClassification.CREDENTIAL.

> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Client Security Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:10:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 14:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8087) Statistics Resources are
 being created without a corresponding ManagementResourceRegistration
In-Reply-To: <JIRA.12676129.1486906132000@Atlassian.JIRA>
References: <JIRA.12676129.1486906132000@Atlassian.JIRA>
	<JIRA.12676129.1486906132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676129.1486906132000.7188.1487013000162@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362785#comment-13362785 ] 

Brian Stansberry commented on WFLY-8087:
----------------------------------------

A bit more on why this happens.

We don't know if the statistics resource is going to be needed until Stage.RUNTIME, as the statistics-enabled attribute allows expressions. Plus, we don't know the exact statistics that will be available until runtime, as those are dependent on the DS/RA implementation. So, the MRR is not registered until RUNTIME. But we don't allow Resource tree changes after Stage.MODEL, and the MSC Service that does the MRR reg can't safely hold a ref to the Resource tree beyond the scope of one op anyway (since a later write op will clone the tree leaving the service with an stale copy.) So to work around this the child statistics resource is always added.

A partial improvement on this is to not add it on an HC, since it's never relevant there and the MRR will never be added. My PR does that.

> Statistics Resources are being created without a corresponding ManagementResourceRegistration
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8087
>                 URL: https://issues.jboss.org/browse/WFLY-8087
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, JMS
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
> I found there were no MRRs for
> /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
> /profile=*/subsystem=datasources/data-source=*/statistics=jdbc
> /profile=*/subsystem=datasources/data-source=*/statistics=pool
> I expect the latter two would be repeated for xa-data-source=*
> Probably the lack of MRR is correct and the problem is the existence of the resource. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:12:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 14:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8087) Statistics Resources are
 being created without a corresponding ManagementResourceRegistration
In-Reply-To: <JIRA.12676129.1486906132000@Atlassian.JIRA>
References: <JIRA.12676129.1486906132000@Atlassian.JIRA>
	<JIRA.12676129.1486906132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676129.1486906132000.7193.1487013120434@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8087:
-----------------------------------
    Priority: Minor  (was: Major)


> Statistics Resources are being created without a corresponding ManagementResourceRegistration
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8087
>                 URL: https://issues.jboss.org/browse/WFLY-8087
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, JMS
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
> I found there were no MRRs for
> /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
> /profile=*/subsystem=datasources/data-source=*/statistics=jdbc
> /profile=*/subsystem=datasources/data-source=*/statistics=pool
> I expect the latter two would be repeated for xa-data-source=*
> Probably the lack of MRR is correct and the problem is the existence of the resource. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:19:00 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Mon, 13 Feb 2017 14:19:00 -0500 (EST)
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: <JIRA.12497139.1374586120000@Atlassian.JIRA>
References: <JIRA.12497139.1374586120000@Atlassian.JIRA>
	<JIRA.12497139.1374586120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.7209.1487013540201@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink reassigned WFLY-1805:
--------------------------------------

    Assignee: David Lloyd


> 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: Feature Request
>          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  Mon Feb 13 14:27:00 2017
From: issues at jboss.org (Joey Wang (JIRA))
Date: Mon, 13 Feb 2017 14:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1548) Access denied when
 deploying to wildfly 10
In-Reply-To: <JIRA.12618242.1462434992000@Atlassian.JIRA>
References: <JIRA.12618242.1462434992000@Atlassian.JIRA>
	<JIRA.12618242.1462434992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618242.1462434992000.7246.1487014020982@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362787#comment-13362787 ] 

Joey Wang commented on WFCORE-1548:
-----------------------------------

We have the same issue with Wildfly 10.1.0.Final in Windows Server 2016. We excluded the Wildfly folder from Windows Defender as workaround.
Will this issue be fixed in Wildfly, or it is not a problem of Wildfly?

> 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  Mon Feb 13 14:39:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 14:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7264.1487014740316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2293:
-------------------------------------
    Description: 
Predominantly the following 6 items are referenced across the application server: -

Authentication Context
Credential Store
HTTP Authentication Factory
SASL Authentication Factory
SSLContext
Security Domain

We should probably represent these as: -

(Authentication Context) -> Authentication Client Ref
(Credential Store) -> Credential
(HTTP / SASL Authentication Factory) -> Authentication Factory Ref
(Security Domain) -> Security Domain Ref
(SSL Context) -> SSL Ref

We already have 'Credential' defined so we can re-use that.


  was:
Predominantly the following 6 items are referenced across the application server: -

Authentication Context
Credential Store
HTTP Authentication Factory
SASL Authentication Factory
SSLContext
Security Domain

We should probably represent these as: -

(Authentication Context) -> Client Security Ref
(Credential Store) -> Credential
(HTTP / SASL Authentication Factory) -> Authentication Factory Ref
(Security Domain) -> Security Domain Ref
(SSL Context) -> SSL Ref

We already have 'Credential' defined so we can re-use that.




> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Authentication Client Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:41:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Feb 2017 14:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8096) Outdated license file in
	infinispan JARs
In-Reply-To: <JIRA.12676261.1486993894000@Atlassian.JIRA>
References: <JIRA.12676261.1486993894000@Atlassian.JIRA>
	<JIRA.12676261.1486993894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676261.1486993894000.7280.1487014860976@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-8096:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)


> Outdated license file in infinispan JARs
> ----------------------------------------
>
>                 Key: WFLY-8096
>                 URL: https://issues.jboss.org/browse/WFLY-8096
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Nikoleta ?iakov?
>            Assignee: Radoslav Husar
>
> Infinispan JARs in EAP distribution contain LICENSE.txt file with LGPL 2.1. However, the correct license in version 8.2.5.Final is ASL 2.0 as stated in https://github.com/infinispan/infinispan/blob/8.2.5.Final/README.md and https://github.com/infinispan/infinispan/blob/8.2.5.Final/license/src/main/resources/META-INF/LICENSE.txt.vm
> The Infinispan license changed in version 6.0.0 (ISPN-3292).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 14:43:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 14:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7333.1487014980811@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362793#comment-13362793 ] 

Darran Lofthouse commented on WFCORE-2293:
------------------------------------------

I think we can re-use the security-domain-ref as well although technically a different security domain they are similar.

> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Authentication Client Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:52:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 13 Feb 2017 14:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.7347.1487015520049@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362797#comment-13362797 ] 

Ken Wills commented on WFCORE-2292:
-----------------------------------

[~darranl]

Quick hack to get this working in core again, I doubt this is the way it's supposed to work, so I won't actually PR this.

https://github.com/luck3y/wildfly-core/commit/6b8bd2b0c112333eba2cc5087c9d9428da9a2d60

> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 14:54:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 14:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7372.1487015640250@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362799#comment-13362799 ] 

Brian Stansberry commented on WFCORE-2293:
------------------------------------------

That's a bit tricky as the old one had more of a "application security" meaning while security-realm-ref was for "management security". That is more a result of where the reference attribute is located though. 

The other thing is the names of legacy security domain names are possibly sensitive (I think; I know the old realms are), while the names of the new ones are not sensitive. So a valid restriction for the old ones will now unnecessarily affect the new ones.

> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Authentication Client Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:07:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 15:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7439.1487016420580@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362804#comment-13362804 ] 

Darran Lofthouse commented on WFCORE-2293:
------------------------------------------

Ok can add an elytron-domain-ref to give them a different meaning.

> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Authentication Client Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:07:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 15:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2293) Centrally define
 sensitivity classifications for references to Elytron capabilities.
In-Reply-To: <JIRA.12676462.1487011626000@Atlassian.JIRA>
References: <JIRA.12676462.1487011626000@Atlassian.JIRA>
	<JIRA.12676462.1487011626000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676462.1487011626000.7447.1487016420795@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362804#comment-13362804 ] 

Darran Lofthouse edited comment on WFCORE-2293 at 2/13/17 3:06 PM:
-------------------------------------------------------------------

Ok can add an elytron-security-domain-ref to give them a different meaning.


was (Author: dlofthouse):
Ok can add an elytron-domain-ref to give them a different meaning.

> Centrally define sensitivity classifications for references to Elytron capabilities.
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2293
>                 URL: https://issues.jboss.org/browse/WFCORE-2293
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta1
>
>
> Predominantly the following 6 items are referenced across the application server: -
> Authentication Context
> Credential Store
> HTTP Authentication Factory
> SASL Authentication Factory
> SSLContext
> Security Domain
> We should probably represent these as: -
> (Authentication Context) -> Authentication Client Ref
> (Credential Store) -> Credential
> (HTTP / SASL Authentication Factory) -> Authentication Factory Ref
> (Security Domain) -> Security Domain Ref
> (SSL Context) -> SSL Ref
> We already have 'Credential' defined so we can re-use that.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:09:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Mon, 13 Feb 2017 15:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-945) User names in Elytron
 FileSystemRealm are not case sensitive on Windows
In-Reply-To: <JIRA.12676469.1487016504000@Atlassian.JIRA>
References: <JIRA.12676469.1487016504000@Atlassian.JIRA>
	<JIRA.12676469.1487016504104@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676469.1487016504000.7470.1487016540489@Atlassian.JIRA>

Josef Cacek created ELY-945:
-------------------------------

             Summary: 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: Darran Lofthouse
            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 Feb 13 15:10:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 15:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8087) Statistics Resources are
 being created without a corresponding ManagementResourceRegistration
In-Reply-To: <JIRA.12676129.1486906132000@Atlassian.JIRA>
References: <JIRA.12676129.1486906132000@Atlassian.JIRA>
	<JIRA.12676129.1486906132000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676129.1486906132000.7476.1487016600274@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362806#comment-13362806 ] 

Brian Stansberry commented on WFLY-8087:
----------------------------------------

The resource-adapter resources will have the same issue on a server, but they don't on an HC. This is because RaAdd is only adding the statistics resource in performRuntime, which doesn't run on an HC.

> Statistics Resources are being created without a corresponding ManagementResourceRegistration
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8087
>                 URL: https://issues.jboss.org/browse/WFLY-8087
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, JMS
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
> I found there were no MRRs for
> /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
> /profile=*/subsystem=datasources/data-source=*/statistics=jdbc
> /profile=*/subsystem=datasources/data-source=*/statistics=pool
> I expect the latter two would be repeated for xa-data-source=*
> Probably the lack of MRR is correct and the problem is the existence of the resource. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:19:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 13 Feb 2017 15:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5158) WARN ISPN000197: Error
 updating cluster member list at the boot up
In-Reply-To: <JIRA.12582115.1440152976000@Atlassian.JIRA>
References: <JIRA.12582115.1440152976000@Atlassian.JIRA>
	<JIRA.12582115.1440152976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12582115.1440152976000.7504.1487017140690@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar resolved WFLY-5158.
----------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> WARN ISPN000197: Error updating cluster member list at the boot up
> ------------------------------------------------------------------
>
>                 Key: WFLY-5158
>                 URL: https://issues.jboss.org/browse/WFLY-5158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.Beta1, 10.0.0.CR2
>            Reporter: Michal Vinkler
>            Assignee: Radoslav Husar
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Seen in ejb-ejbservlet and http-session scenarios intermittently (no matter what failover type or cache is used). 
> When node perf18 is restarted after failover other servers log this error several times: 
> {code}
> [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:752)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$6(JGroupsTransport.java:599)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$34/238012590.apply(Unknown Source)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] 	at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] 	at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.RspListFuture.timeout(RspListFuture.java:40)
> [JBossINF] 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$$Lambda$32/2073718099.run(Unknown Source)
> [JBossINF] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [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-ejb-ejbservlet-jvmkill-repl-async/4/console-perf19/
> In this particular test run, after perf18 restarted , perf19 logged the first error in 2 seconds, perf20 in 30 seconds, perf21 in 10 seconds.
> timeline:
> {code}
> perf18: [JBossINF] [0m[0m16:11:42,361 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Beta1) started in 20244ms - Started 747 of 993 services (424 services are lazy, passive or on-demand)
> perf19: [JBossINF] [0m[31m16:11:43,595 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-107) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> perf20: [JBossINF] [0m[31m16:12:12,836 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-51) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> perf21: [JBossINF] [0m[31m16:11:52,826 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-22) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf18
> {code}
> This error also intermittently appears after server is shutdown.
> Total number of errors for this particular test run: 1183



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:36:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 13 Feb 2017 15:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8092) Fix Elytron Enabled
 attributes at ResourceAdapters subsystem
In-Reply-To: <JIRA.12676148.1486969747000@Atlassian.JIRA>
References: <JIRA.12676148.1486969747000@Atlassian.JIRA>
	<JIRA.12676148.1486969747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676148.1486969747000.7608.1487018160762@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-8092.
------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> Fix Elytron Enabled attributes at ResourceAdapters subsystem
> ------------------------------------------------------------
>
>                 Key: WFLY-8092
>                 URL: https://issues.jboss.org/browse/WFLY-8092
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>             Fix For: 11.0.0.Alpha1
>
>
> This Jira is for all ELYTRON_ENABLED attributes defined in resource adapters subsystem.
> The attribute definition has two bugs: 
> - alternatives defined:
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid.
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at RaAdd.
> - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a  <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:56:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 13 Feb 2017 15:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-945) User names in Elytron
 FileSystemRealm are not case sensitive on Windows
In-Reply-To: <JIRA.12676469.1487016504000@Atlassian.JIRA>
References: <JIRA.12676469.1487016504000@Atlassian.JIRA>
	<JIRA.12676469.1487016504000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676469.1487016504000.7762.1487019360346@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362828#comment-13362828 ] 

David Lloyd commented on ELY-945:
---------------------------------

Maybe user names in any realm should be case-insensitive (relative to the ROOT locale).  Having two users that only differ by case also seems like a potential security issue, and many existing systems (such as email and DNS) that use names as principals in various capacity are also case-insensitive.

> 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: Darran Lofthouse
>            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 Feb 13 15:56:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 13 Feb 2017 15:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8097) Coverity static analysis,
 suspicious bitwise logical expression, DigestUtil (Elytron)
In-Reply-To: <JIRA.12676266.1486995215000@Atlassian.JIRA>
References: <JIRA.12676266.1486995215000@Atlassian.JIRA>
	<JIRA.12676266.1486995215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676266.1486995215000.7777.1487019360803@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8097:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-8097
>                 URL: https://issues.jboss.org/browse/WFLY-8097
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9563899&defectInstanceId=2359232&mergedDefectId=1377462
> See detailed description of possible problem in [1]
> If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails
> {code}
>         byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
>         assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
> {code}
> If I change decodeByteOrderedInteger implementation according to [1], all tests passes.
> {code}
> result |= (buf[offset + i] & 0xff);
> {code}
> [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE
> Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:57:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 13 Feb 2017 15:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-946) Coverity static analysis,
 suspicious bitwise logical expression, DigestUtil (Elytron)
In-Reply-To: <JIRA.12676266.1486995215000@Atlassian.JIRA>
References: <JIRA.12676266.1486995215000@Atlassian.JIRA>
	<JIRA.12676266.1486995215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676266.1486995215000.7780.1487019420172@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-8097 to ELY-946:
-----------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-946  (was: WFLY-8097)
    Component/s: SASL
                     (was: Security)


> Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
> -------------------------------------------------------------------------------------
>
>                 Key: ELY-946
>                 URL: https://issues.jboss.org/browse/ELY-946
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9563899&defectInstanceId=2359232&mergedDefectId=1377462
> See detailed description of possible problem in [1]
> If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails
> {code}
>         byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
>         assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
> {code}
> If I change decodeByteOrderedInteger implementation according to [1], all tests passes.
> {code}
> result |= (buf[offset + i] & 0xff);
> {code}
> [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE
> Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 15:59:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 13 Feb 2017 15:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-945) User names in Elytron
 FileSystemRealm are not case sensitive on Windows
In-Reply-To: <JIRA.12676469.1487016504000@Atlassian.JIRA>
References: <JIRA.12676469.1487016504000@Atlassian.JIRA>
	<JIRA.12676469.1487016504000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676469.1487016504000.7810.1487019540373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362829#comment-13362829 ] 

David Lloyd commented on ELY-945:
---------------------------------

On a similar token, it seems like a really good idea to perform Unicode NFKC normalization as well for the same reason.  For more info see [the JDK docs for java.text.Normalizer|http://download.java.net/java/jdk9/docs/api/index.html?java/text/Normalizer.html].

> 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: Darran Lofthouse
>            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 Feb 13 17:33:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 13 Feb 2017 17:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8100) Use
 RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
In-Reply-To: <JIRA.12676499.1487025177000@Atlassian.JIRA>
References: <JIRA.12676499.1487025177000@Atlassian.JIRA>
	<JIRA.12676499.1487025177976@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676499.1487025177000.8161.1487025180101@Atlassian.JIRA>

Paul Ferraro created WFLY-8100:
----------------------------------

             Summary: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
                 Key: WFLY-8100
                 URL: https://issues.jboss.org/browse/WFLY-8100
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 10.1.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 18:37:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 13 Feb 2017 18:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8101) Add access constraints to
 resources referencing Elytron capabilities
In-Reply-To: <JIRA.12676505.1487028979000@Atlassian.JIRA>
References: <JIRA.12676505.1487028979000@Atlassian.JIRA>
	<JIRA.12676505.1487028979333@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676505.1487028979000.8335.1487029020386@Atlassian.JIRA>

Darran Lofthouse created WFLY-8101:
--------------------------------------

             Summary: Add access constraints to resources referencing Elytron capabilities
                 Key: WFLY-8101
                 URL: https://issues.jboss.org/browse/WFLY-8101
             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 Feb 13 21:24:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Feb 2017 21:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1439) DMN engine is eagerly
 evaluating variables in unary test lists
In-Reply-To: <JIRA.12676508.1487039038000@Atlassian.JIRA>
References: <JIRA.12676508.1487039038000@Atlassian.JIRA>
	<JIRA.12676508.1487039038558@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676508.1487039038000.8399.1487039040064@Atlassian.JIRA>

Edson Tirelli created DROOLS-1439:
-------------------------------------

             Summary: DMN engine is eagerly evaluating variables in unary test lists
                 Key: DROOLS-1439
                 URL: https://issues.jboss.org/browse/DROOLS-1439
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
            Priority: Critical
             Fix For: 7.0.0.Final


When entering test in decision table, we usually omit the ?=? characters. If there is nothing, it is assumed to be an equal test. When executing with Redhat, this works fine except if I use variable to do the testing. In that case, I need to put the ?=? sign for the execution do produce the proper result, otherwise when the value is equals I get null.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 21:28:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Feb 2017 21:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1439) DMN engine is eagerly
 evaluating variables in unary test lists
In-Reply-To: <JIRA.12676508.1487039039000@Atlassian.JIRA>
References: <JIRA.12676508.1487039039000@Atlassian.JIRA>
	<JIRA.12676508.1487039039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676508.1487039039000.8401.1487039280053@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362863#comment-13362863 ] 

Edson Tirelli commented on DROOLS-1439:
---------------------------------------

Fixed in PR: https://github.com/droolsjbpm/kie-dmn/pull/39


> DMN engine is eagerly evaluating variables in unary test lists
> --------------------------------------------------------------
>
>                 Key: DROOLS-1439
>                 URL: https://issues.jboss.org/browse/DROOLS-1439
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> When entering test in decision table, we usually omit the ?=? characters. If there is nothing, it is assumed to be an equal test. When executing with Redhat, this works fine except if I use variable to do the testing. In that case, I need to put the ?=? sign for the execution do produce the proper result, otherwise when the value is equals I get null.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 21:35:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 13 Feb 2017 21:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2286)
 GenericSubsystemDescribeHandler generates duplicates operations for
 override models
In-Reply-To: <JIRA.12676052.1486757675000@Atlassian.JIRA>
References: <JIRA.12676052.1486757675000@Atlassian.JIRA>
	<JIRA.12676052.1486757675000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676052.1486757675000.8405.1487039700114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362864#comment-13362864 ] 

Brian Stansberry commented on WFCORE-2286:
------------------------------------------

[~pferraro] plan is to do a core release tomorrow so after that this should be fixed in full.

> GenericSubsystemDescribeHandler generates duplicates operations for override models
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2286
>                 URL: https://issues.jboss.org/browse/WFCORE-2286
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha24
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta1
>
>
> Currently, GenericSubsystemDescribeHandler relies on ImmutableManagementResourceRegistration.getChildAddresses(...) to find child resources.  When processing a wildcard address, all resource children are matched. Thus any non-wildcard paths returned by getChildAddresses(...) for the same child type will end up being described twice.  Additionally, child order needs to be preserved, even in the presence of override models.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 22:29:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 13 Feb 2017 22:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1436) Unable to create runtime
 for the attached DMN model
In-Reply-To: <JIRA.12676071.1486763915000@Atlassian.JIRA>
References: <JIRA.12676071.1486763915000@Atlassian.JIRA>
	<JIRA.12676071.1486763915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676071.1486763915000.8411.1487042940155@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13362866#comment-13362866 ] 

Edson Tirelli commented on DROOLS-1436:
---------------------------------------

Melanie,

The problem reported here is fixed by DROOLS-1432 and DROOLS-1439. It will be fixed as soon as the following PR is merged:

https://github.com/droolsjbpm/kie-dmn/pull/35

I will update this ticket once it is done.

> Unable to create runtime for the attached DMN model
> ---------------------------------------------------
>
>                 Key: DROOLS-1436
>                 URL: https://issues.jboss.org/browse/DROOLS-1436
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: M?lanie Gauthier
>            Assignee: Edson Tirelli
>         Attachments: Get Viable Loan Products.dmn
>
>
> When trying to load that model, the following errors is logged:
>  java.lang.IllegalStateException: [Message [id=1, kieBase=defaultKieBase, level=ERROR, path=trisotech/Get_Viable_Loan_Products.dmn, line=-1, column=0
>    text=Unable to compile DMN model for the resource]]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 13 22:59:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 13 Feb 2017 22:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-7) Migrate pool module from existent
	POC repo
In-Reply-To: <JIRA.12675847.1486671449000@Atlassian.JIRA>
References: <JIRA.12675847.1486671449000@Atlassian.JIRA>
	<JIRA.12675847.1486671449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675847.1486671449000.8414.1487044740218@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-7.
----------------------------
    Fix Version/s: 0.0.1
       Resolution: Done


> Migrate pool module from existent POC repo
> ------------------------------------------
>
>                 Key: AG-7
>                 URL: https://issues.jboss.org/browse/AG-7
>             Project: Agroal
>          Issue Type: Task
>          Components: pool
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.0.1
>
>
> Move the connection pool code (integrated-object-pool) currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.
> Rename packages and classes to io.agroal.pool.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 23:20:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 13 Feb 2017 23:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-6) Migrate API module from existent
	POC repo
In-Reply-To: <JIRA.12675570.1486568716000@Atlassian.JIRA>
References: <JIRA.12675570.1486568716000@Atlassian.JIRA>
	<JIRA.12675570.1486568716000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675570.1486568716000.8440.1487046000173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro updated AG-6:
---------------------------
    Affects Version/s: 0.0


> Migrate API module from existent POC repo
> -----------------------------------------
>
>                 Key: AG-6
>                 URL: https://issues.jboss.org/browse/AG-6
>             Project: Agroal
>          Issue Type: Task
>          Components: api
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>
> Move the API code currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.
> Rename packages and classes to io.agroal.api.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 23:20:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 13 Feb 2017 23:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-7) Migrate pool module from existent
	POC repo
In-Reply-To: <JIRA.12675847.1486671449000@Atlassian.JIRA>
References: <JIRA.12675847.1486671449000@Atlassian.JIRA>
	<JIRA.12675847.1486671449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675847.1486671449000.8443.1487046000238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro updated AG-7:
---------------------------
    Affects Version/s: 0.0


> Migrate pool module from existent POC repo
> ------------------------------------------
>
>                 Key: AG-7
>                 URL: https://issues.jboss.org/browse/AG-7
>             Project: Agroal
>          Issue Type: Task
>          Components: pool
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>
> Move the connection pool code (integrated-object-pool) currently on https://github.com/barreiro/datasource-subsystem-poc/ to Agroal's git repo.
> Rename packages and classes to io.agroal.pool.*



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 13 23:21:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 13 Feb 2017 23:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-8) Migrate Narayana integration
 module from existent POC repo
In-Reply-To: <JIRA.12676510.1487046001000@Atlassian.JIRA>
References: <JIRA.12676510.1487046001000@Atlassian.JIRA>
	<JIRA.12676510.1487046001332@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676510.1487046001000.8446.1487046060112@Atlassian.JIRA>

Luis Barreiro created AG-8:
------------------------------

             Summary: Migrate Narayana integration module from existent POC repo
                 Key: AG-8
                 URL: https://issues.jboss.org/browse/AG-8
             Project: Agroal
          Issue Type: Task
          Components: narayana
    Affects Versions: 0.0
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
             Fix For: 0.1






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 01:13:00 2017
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Tue, 14 Feb 2017 01:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8102) Wrong management address used
 for graceful shutdown XTS tests
In-Reply-To: <JIRA.12676511.1487052102000@Atlassian.JIRA>
References: <JIRA.12676511.1487052102000@Atlassian.JIRA>
	<JIRA.12676511.1487052102000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676511.1487052102000.8466.1487052780079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky moved JBEAP-8811 to WFLY-8102:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8102  (was: JBEAP-8811)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Test Suite
                           (was: Test Suite)
       Target Release:   (was: 7.1.0.GA)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR11)


> Wrong management address used for graceful shutdown XTS tests
> -------------------------------------------------------------
>
>                 Key: WFLY-8102
>                 URL: https://issues.jboss.org/browse/WFLY-8102
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.Final
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> "alternative-server" of wildfly-ts-integ-xts module use wrong managementAddress
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/xts/src/test/config/arq/arquillian.xml
> "alternative-server" use 100 port offset, but doesn't change the managementAddress, this make tests fail with "Could not start container" in case that node0 is not binded to localhost
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/src/test/scripts/xts-build.xml
> *reproduce*
> # $MYTESTIP_1 != localhost 
> {noformat}
> ./integration-tests.sh -Dts.xts  -Dts.noSmoke -Dnode0=$MYTESTIP_1
> Tests in error: 
>   CompensatableTestCase.org.jboss.as.test.xts.annotation.client.CompensatableTestCase ? Runtime
>   TransactionalTestCase.org.jboss.as.test.xts.annotation.client.TransactionalTestCase ? Runtime
>   CompensationScopedTestCase.org.jboss.as.test.xts.annotation.compensationScoped.CompensationScopedTestCase ? Runtime
>   AtomicTransactionSuspendTestCase.org.jboss.as.test.xts.suspend.wsat.AtomicTransactionSuspendTestCase ? Lifecycle
>   BusinessActivitySuspendTestCase.org.jboss.as.test.xts.suspend.wsba.BusinessActivitySuspendTestCase ? Runtime
>   ATTestCase.org.jboss.as.test.xts.wsat.client.ATTestCase ? Runtime Arquillian h...
>   BACoordinatorCompletionTestCase.org.jboss.as.test.xts.wsba.coordinatorcompletion.client.BACoordinatorCompletionTestCase ? Runtime
>   BAParticipantCompletionTestCase.org.jboss.as.test.xts.wsba.participantcompletion.client.BAParticipantCompletionTestCase ? Runtime
> Tests run: 8, Failures: 0, Errors: 8, Skipped: 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 01:55:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 01:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8103) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676517.1487055265000@Atlassian.JIRA>
References: <JIRA.12676517.1487055265000@Atlassian.JIRA>
	<JIRA.12676517.1487055265378@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676517.1487055265000.8525.1487055300573@Atlassian.JIRA>

Martin Choma created WFLY-8103:
----------------------------------

             Summary: Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
                 Key: WFLY-8103
                 URL: https://issues.jboss.org/browse/WFLY-8103
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Coverity found 2 occurences of possible null dereference.
https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359322&mergedDefectId=1395584
https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359323&mergedDefectId=1395585

Method {{resolvePassword()}} is dereferencing {{resolvedPath}} field
{code}
    private char[] resolvePassword() throws Exception {
        ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
        CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
        if (cs != null) {
            return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
        } else {
            throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
        }
    }
{code}

And method {{resolvePassword()}} is called 2 times from block, where resolvedPath is checked on null
{code}
    try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
        AtomicLoadKeyStore.LoadKey loadKey = keyStore.revertibleLoad(is, resolvePassword());

    try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
        char[] password = resolvePassword();
{code}

Add null check into {{resolvePassword()}} method.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 02:00:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 14 Feb 2017 02:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7168) Complex type
 sasl-authentication-factory in Elytron subsystem
In-Reply-To: <JIRA.12651181.1474461452000@Atlassian.JIRA>
References: <JIRA.12651181.1474461452000@Atlassian.JIRA>
	<JIRA.12651181.1474461452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651181.1474461452000.8536.1487055600620@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-7168:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Complex type sasl-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-7168
>                 URL: https://issues.jboss.org/browse/WFLY-7168
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in sasl-authentication-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 Feb 14 02:00:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 14 Feb 2017 02:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7168) Complex type
 sasl-authentication-factory in Elytron subsystem
In-Reply-To: <JIRA.12651181.1474461452000@Atlassian.JIRA>
References: <JIRA.12651181.1474461452000@Atlassian.JIRA>
	<JIRA.12651181.1474461452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651181.1474461452000.8543.1487055601026@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7168:
-----------------------------
    Description: 
Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

Complex attributes in add operation and resource description:
mechanism-configurations
mechanism-realm-configurations

  was:Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.



> Complex type sasl-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-7168
>                 URL: https://issues.jboss.org/browse/WFLY-7168
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex attributes in add operation and resource description:
> mechanism-configurations
> mechanism-realm-configurations



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 02:19:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 02:19:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8104) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676520.1487056738000@Atlassian.JIRA>
References: <JIRA.12676520.1487056738000@Atlassian.JIRA>
	<JIRA.12676520.1487056738747@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676520.1487056738000.8580.1487056741398@Atlassian.JIRA>

Martin Choma created WFLY-8104:
----------------------------------

             Summary: Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
                 Key: WFLY-8104
                 URL: https://issues.jboss.org/browse/WFLY-8104
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


Coverity found 2 possible occurences of dereferencing null.

https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359321&mergedDefectId=1395588
https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359320&mergedDefectId=1396462

{code:java}
    private char[] resolvePassword() throws Exception {
        ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
        CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
        if (cs != null) {
            return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
        } else {
            throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
        }
    }
{code}

Both {{getCredential(Class<C> credentialType)}} and {{getPassword(Class<P> type)}} have in javadoc mentioned return value can be null.

Also in org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder.SimpleDirContextFactory.obtainDirContext(org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode) returned value are explicitely checked on null value.

Add null check also in {{resolvePassword()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 02:34:00 2017
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 02:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8105) Distributed workmanager can
 only be removed in admin-only mode
In-Reply-To: <JIRA.12676523.1487057494000@Atlassian.JIRA>
References: <JIRA.12676523.1487057494000@Atlassian.JIRA>
	<JIRA.12676523.1487057494000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676523.1487057494000.8654.1487057640343@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k moved JBEAP-8815 to WFLY-8105:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8105  (was: JBEAP-8815)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: CLI
                       JCA
                           (was: JCA)
    Affects Version/s: 11.0.0.Alpha1
                           (was: 7.1.0.DR11)


> Distributed workmanager can only be removed in admin-only mode
> --------------------------------------------------------------
>
>                 Key: WFLY-8105
>                 URL: https://issues.jboss.org/browse/WFLY-8105
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Stefano Maestri
>
> See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode.
> It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 02:34:00 2017
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 02:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8105) Distributed workmanager can
 only be removed in admin-only mode
In-Reply-To: <JIRA.12676523.1487057494000@Atlassian.JIRA>
References: <JIRA.12676523.1487057494000@Atlassian.JIRA>
	<JIRA.12676523.1487057494000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676523.1487057494000.8658.1487057640462@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k updated WFLY-8105:
--------------------------------
    Description: 
See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode.

It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload.

Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff

  was:
See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode.

It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload.



> Distributed workmanager can only be removed in admin-only mode
> --------------------------------------------------------------
>
>                 Key: WFLY-8105
>                 URL: https://issues.jboss.org/browse/WFLY-8105
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Stefano Maestri
>
> See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode.
> It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload.
> Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 02:35:00 2017
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 02:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8105) Distributed workmanager can
 only be removed in admin-only mode
In-Reply-To: <JIRA.12676523.1487057494000@Atlassian.JIRA>
References: <JIRA.12676523.1487057494000@Atlassian.JIRA>
	<JIRA.12676523.1487057494000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676523.1487057494000.8667.1487057700515@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k updated WFLY-8105:
--------------------------------
    Component/s:     (was: CLI)


> Distributed workmanager can only be removed in admin-only mode
> --------------------------------------------------------------
>
>                 Key: WFLY-8105
>                 URL: https://issues.jboss.org/browse/WFLY-8105
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Stefano Maestri
>
> See the steps to reproduce. It is not possible to remove a distributed workmanager once it has been created, except in admin-only mode.
> It is expected that if a command is valid - it should pass in both normal and admin-only mode. The exception being, that if the resource being removed cannot be removed while the server is running, the command should still pass, but should require server reload. Note that from user-experience standpoint, as few operations as possible should require server reload.
> Can be reproduced with wildfly master, exact commit: f16940f5e6bb939e0140a2327e3a91717f3869ff



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 03:09:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 03:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Use TimeoutUtil in TS
In-Reply-To: <JIRA.12676532.1487059697000@Atlassian.JIRA>
References: <JIRA.12676532.1487059697000@Atlassian.JIRA>
	<JIRA.12676532.1487059697674@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059697000.8896.1487059740060@Atlassian.JIRA>

Marek Kopeck? created WFCORE-2294:
-------------------------------------

             Summary: Use TimeoutUtil in TS
                 Key: WFCORE-2294
                 URL: https://issues.jboss.org/browse/WFCORE-2294
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Test Suite
            Reporter: Marek Kopeck?
            Assignee: Marek Kopeck?


Use TimeoutUtil in TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* TestRunner should use TimeoutUtil for timeout
* CliProcessWrapper.java should use TimeoutUtil for timeout



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 03:28:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 03:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8106) Coverity static analysis,
 Dereference null return value,
 CredentialStoreAliasDefinition (elytron-subsystem)
In-Reply-To: <JIRA.12676545.1487060849000@Atlassian.JIRA>
References: <JIRA.12676545.1487060849000@Atlassian.JIRA>
	<JIRA.12676545.1487060849883@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676545.1487060849000.9042.1487060881136@Atlassian.JIRA>

Martin Choma created WFLY-8106:
----------------------------------

             Summary: Coverity static analysis, Dereference null return value, CredentialStoreAliasDefinition (elytron-subsystem) 
                 Key: WFLY-8106
                 URL: https://issues.jboss.org/browse/WFLY-8106
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Coverity found 2 possible occurences of dereferencing null. Method {{propertyAliasFromOperation(final ModelNode operation)}} can return null.
And return value of {{propertyAliasFromOperation(final ModelNode operation)}} is dereferenced in {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}}

{code:java}
    private static void transformOperationAddress(final ModelNode operation) {
        Property alias = propertyAliasFromOperation(operation);
        String newAlias = alias.getValue().asString().toLowerCase(Locale.ROOT);
        alias.getValue().set(newAlias);
    }

    private static boolean sameAlias(final OperationContext context, final ModelNode operation) {
        String contextAlias = context.getCurrentAddress().getLastElement().getValue();
        String operationAlias = propertyAliasFromOperation(operation).getValue().asString();
        return  operationAlias.equals(contextAlias);
    }

    private static Property propertyAliasFromOperation(final ModelNode operation) {
        ModelNode address = operation.get(ModelDescriptionConstants.OP_ADDR);
        List<Property> list = address.asPropertyList();
        Property alias = null;
        for (Property p: list) {
            if (ElytronDescriptionConstants.ALIAS.equals(p.getName())) {
                alias = p;
                break;
            }
        }
        return alias;
    }
{code}

Add null check into {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 03:46:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 03:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8107) Coverity static analysis,
 Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
In-Reply-To: <JIRA.12676552.1487061916000@Atlassian.JIRA>
References: <JIRA.12676552.1487061916000@Atlassian.JIRA>
	<JIRA.12676552.1487061916982@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676552.1487061916000.9168.1487061960759@Atlassian.JIRA>

Martin Choma created WFLY-8107:
----------------------------------

             Summary: Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
                 Key: WFLY-8107
                 URL: https://issues.jboss.org/browse/WFLY-8107
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.

{code:java}
    private X509Certificate getClientCertificate() throws SaslException {
        if ((clientCertChain != null) && (clientCertChain.length > 0)) {
            return clientCertChain[0];
        } else if (clientCertUrl != null) {
            try {
                return EntityUtil.getCertificateFromUrl(clientCertUrl);
            } catch (IOException e) {
                throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
            }
        } else {
            throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
        }
    }
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 04:25:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 04:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Use TimeoutUtil in TS
In-Reply-To: <JIRA.12676532.1487059698000@Atlassian.JIRA>
References: <JIRA.12676532.1487059698000@Atlassian.JIRA>
	<JIRA.12676532.1487059698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059698000.9518.1487064300337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-2294:
----------------------------------
    Description: 
Use TimeoutUtil in TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner 
* CliProcessWrapper.java should use TimeoutUtil for timeout

  was:
Use TimeoutUtil in TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* TestRunner should use TimeoutUtil for timeout
* CliProcessWrapper.java should use TimeoutUtil for timeout



> Use TimeoutUtil in TS
> ---------------------
>
>                 Key: WFCORE-2294
>                 URL: https://issues.jboss.org/browse/WFCORE-2294
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Use TimeoutUtil in TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner 
> * CliProcessWrapper.java should use TimeoutUtil for timeout



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 04:29:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 04:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE
	TS
In-Reply-To: <JIRA.12676532.1487059698000@Atlassian.JIRA>
References: <JIRA.12676532.1487059698000@Atlassian.JIRA>
	<JIRA.12676532.1487059698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059698000.9550.1487064540384@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-2294:
----------------------------------
    Summary: Improve timeouts in WF-CORE TS  (was: Use TimeoutUtil in TS)


> Improve timeouts in WF-CORE TS
> ------------------------------
>
>                 Key: WFCORE-2294
>                 URL: https://issues.jboss.org/browse/WFCORE-2294
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Use TimeoutUtil in TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner 
> * CliProcessWrapper.java should use TimeoutUtil for timeout



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 04:35:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 04:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE
	TS
In-Reply-To: <JIRA.12676532.1487059698000@Atlassian.JIRA>
References: <JIRA.12676532.1487059698000@Atlassian.JIRA>
	<JIRA.12676532.1487059698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059698000.9598.1487064900216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-2294:
----------------------------------
    Description: 
Improve timeouts in WF-CORE TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner 
* CliProcessWrapper.java should use TimeoutUtil for timeout

  was:
Use TimeoutUtil in TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner 
* CliProcessWrapper.java should use TimeoutUtil for timeout



> Improve timeouts in WF-CORE TS
> ------------------------------
>
>                 Key: WFCORE-2294
>                 URL: https://issues.jboss.org/browse/WFCORE-2294
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in WF-CORE TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner 
> * CliProcessWrapper.java should use TimeoutUtil for timeout



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 04:40:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 04:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE
	TS
In-Reply-To: <JIRA.12676532.1487059698000@Atlassian.JIRA>
References: <JIRA.12676532.1487059698000@Atlassian.JIRA>
	<JIRA.12676532.1487059698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059698000.9656.1487065200563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-2294:
----------------------------------
    Affects Version/s: 3.0.0.Alpha22


> Improve timeouts in WF-CORE TS
> ------------------------------
>
>                 Key: WFCORE-2294
>                 URL: https://issues.jboss.org/browse/WFCORE-2294
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 3.0.0.Alpha22
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in WF-CORE TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner 
> * CliProcessWrapper.java should use TimeoutUtil for timeout



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 05:15:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 05:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8108) Elytron subsystem is unable
 to configure SunPKCS11 provider
In-Reply-To: <JIRA.12676566.1487067270000@Atlassian.JIRA>
References: <JIRA.12676566.1487067270000@Atlassian.JIRA>
	<JIRA.12676566.1487067270671@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676566.1487067270000.9941.1487067300782@Atlassian.JIRA>

Martin Choma created WFLY-8108:
----------------------------------

             Summary: Elytron subsystem is unable to configure SunPKCS11 provider
                 Key: WFLY-8108
                 URL: https://issues.jboss.org/browse/WFLY-8108
             Project: WildFly
          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.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.<init>(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 Feb 14 05:30:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 14 Feb 2017 05:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7175) Complex type
 server-ssl-context/ssl-session in Elytron subsystem
In-Reply-To: <JIRA.12651200.1474462474000@Atlassian.JIRA>
References: <JIRA.12651200.1474462474000@Atlassian.JIRA>
	<JIRA.12651200.1474462474000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651200.1474462474000.9998.1487068200465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reopened WFLY-7175:
------------------------------


Forgot to update definitions, updated in handlers only...

> Complex type server-ssl-context/ssl-session in Elytron subsystem
> ----------------------------------------------------------------
>
>                 Key: WFLY-7175
>                 URL: https://issues.jboss.org/browse/WFLY-7175
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in server-ssl-context resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Details: *server-ssl-context/ssl-session* - nested complex attributes (not critical in the short term - although exposing management information that provides insight into the current sessions would be a big bonus for administrators)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 05:46:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 14 Feb 2017 05:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1548) Access denied when
 deploying to wildfly 10
In-Reply-To: <JIRA.12618242.1462434992000@Atlassian.JIRA>
References: <JIRA.12618242.1462434992000@Atlassian.JIRA>
	<JIRA.12618242.1462434992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618242.1462434992000.10063.1487069160440@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363009#comment-13363009 ] 

Tomaz Cerar commented on WFCORE-1548:
-------------------------------------

If issue only occurs when antirvirus/antimalware/application firewall is running and causing this. 
I don't see how we could fix that in our code as it is out of our hands what OS (and its tools) do to files / folders we try to access.

It is annoying but more problem with antivirus/antimalware than anything else.

> 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  Tue Feb 14 06:03:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 14 Feb 2017 06:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7164) Complex type
 http-authentication-factory in Elytron subsystem
In-Reply-To: <JIRA.12651162.1474458178000@Atlassian.JIRA>
References: <JIRA.12651162.1474458178000@Atlassian.JIRA>
	<JIRA.12651162.1474458178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651162.1474458178000.10146.1487070180764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7164:
-----------------------------
    Description: 
Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.

Complex attributes in add operation and resource description:
mechanism-configurations
mechanism-realm-configurations.

  was:Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.



> Complex type http-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-7164
>                 URL: https://issues.jboss.org/browse/WFLY-7164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex attributes in add operation and resource description:
> mechanism-configurations
> mechanism-realm-configurations.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 06:22:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 06:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071265000@Atlassian.JIRA>
References: <JIRA.12676576.1487071265000@Atlassian.JIRA>
	<JIRA.12676576.1487071265906@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071265000.10350.1487071320067@Atlassian.JIRA>

Marek Kopeck? created WFLY-8109:
-----------------------------------

             Summary: Improve timeouts in AS TS
                 Key: WFLY-8109
                 URL: https://issues.jboss.org/browse/WFLY-8109
             Project: WildFly
          Issue Type: Enhancement
          Components: Test Suite
            Reporter: Marek Kopeck?
            Assignee: Marek Kopeck?


Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 06:57:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2294) Improve timeouts in WF-CORE
	TS
In-Reply-To: <JIRA.12676532.1487059698000@Atlassian.JIRA>
References: <JIRA.12676532.1487059698000@Atlassian.JIRA>
	<JIRA.12676532.1487059698000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676532.1487059698000.10607.1487073420307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-2294:
----------------------------------
    Description: 
Improve timeouts in WF-CORE TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner 
* CliProcessWrapper.java should use TimeoutUtil for timeout

This stabilizes TS on slower machines.

  was:
Improve timeouts in WF-CORE TS
* SuspendResumeTestCase.java should use TimeoutUtil for timeout
* Parametrize timeouts in TestRunner 
* CliProcessWrapper.java should use TimeoutUtil for timeout



> Improve timeouts in WF-CORE TS
> ------------------------------
>
>                 Key: WFCORE-2294
>                 URL: https://issues.jboss.org/browse/WFCORE-2294
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 3.0.0.Alpha22
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in WF-CORE TS
> * SuspendResumeTestCase.java should use TimeoutUtil for timeout
> * Parametrize timeouts in TestRunner 
> * CliProcessWrapper.java should use TimeoutUtil for timeout
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 06:57:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071266000@Atlassian.JIRA>
References: <JIRA.12676576.1487071266000@Atlassian.JIRA>
	<JIRA.12676576.1487071266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071266000.10613.1487073420704@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-8109:
--------------------------------
    Description: 
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.

  was:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]



> Improve timeouts in AS TS
> -------------------------
>
>                 Key: WFLY-8109
>                 URL: https://issues.jboss.org/browse/WFLY-8109
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase timeout in LegacyConfigTest
> * increase timeout in DomainHostExcludesTest
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 07:12:00 2017
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 07:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8110) Submitting work with
 distributed workmanager fails with null securityIntegration
In-Reply-To: <JIRA.12676617.1487074278000@Atlassian.JIRA>
References: <JIRA.12676617.1487074278000@Atlassian.JIRA>
	<JIRA.12676617.1487074278000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676617.1487074278000.10759.1487074320872@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k moved JBEAP-8822 to WFLY-8110:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8110  (was: JBEAP-8822)
             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.DR11)


> Submitting work with distributed workmanager fails with null securityIntegration
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-8110
>                 URL: https://issues.jboss.org/browse/WFLY-8110
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Stefano Maestri
>            Priority: Critical
>
> When implementing tests for EAP7-495, I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
> {code}
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
> 	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:73)
> 	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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
> 	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.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	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.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
> 	at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
> 	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: Null security integration
> 	at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
> 	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
> 	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
> 	at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.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:240)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 	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:240)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> 	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.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 40 more
> {code}
> The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
> I found that an ordinary workmanager service contains the following:
> {{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
> and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
> Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
> There might be some concerns about Elytron integration too, but I leave that to [~msimka].
> I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 07:13:00 2017
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Tue, 14 Feb 2017 07:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8110) Submitting work with
 distributed workmanager fails with null securityIntegration
In-Reply-To: <JIRA.12676617.1487074278000@Atlassian.JIRA>
References: <JIRA.12676617.1487074278000@Atlassian.JIRA>
	<JIRA.12676617.1487074278000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676617.1487074278000.10762.1487074380126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k updated WFLY-8110:
--------------------------------
    Description: 
I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
{code}
javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
	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:73)
	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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
	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.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
	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.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
	at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
	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: Null security integration
	at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
	at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.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:240)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
	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:240)
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
	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.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
	... 40 more
{code}

The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.

I found that an ordinary workmanager service contains the following:
{{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.

Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.

There might be some concerns about Elytron integration too, but I leave that to [~msimka].

I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.

Found with commit: 8d587934b771cf91425ea3e06d23dcd7f145e9ef

  was:
When implementing tests for EAP7-495, I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
{code}
javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
	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:73)
	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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
	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.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
	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.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
	at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
	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: Null security integration
	at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
	at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
	at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.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:240)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
	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:240)
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
	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.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
	... 40 more
{code}

The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.

I found that an ordinary workmanager service contains the following:
{{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.

Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.

There might be some concerns about Elytron integration too, but I leave that to [~msimka].

I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.



> Submitting work with distributed workmanager fails with null securityIntegration
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-8110
>                 URL: https://issues.jboss.org/browse/WFLY-8110
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Stefano Maestri
>            Priority: Critical
>
> I tried submitting some work items via a distributed workmanager via {{NamedDistributedWorkManager.doWork()}}. This failed with:
> {code}
> javax.ejb.EJBException: java.lang.IllegalArgumentException: Null security integration
> 	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:73)
> 	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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:70)
> 	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.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	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.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:413)
> 	at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:158)
> 	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: Null security integration
> 	at org.jboss.jca.core.workmanager.WorkWrapper.<init>(WorkWrapper.java:129)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.createWorkWrapper(WorkManagerImpl.java:738)
> 	at org.jboss.jca.core.workmanager.WorkManagerImpl.doWork(WorkManagerImpl.java:459)
> 	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.localDoWork(DistributedWorkManagerImpl.java:304)
> 	at org.jboss.jca.core.workmanager.DistributedWorkManagerImpl.doWork(DistributedWorkManagerImpl.java:389)
> 	at org.jboss.as.test.integration.jca.workmanager.distributed.DwmAdminObjectEjbImpl.doWork(DwmAdminObjectEjbImpl.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:240)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 	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:240)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> 	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.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 40 more
> {code}
> The {{EJBException}} is an implementation detail of my test. The cause of the exception - {{IllegalArgumentException: Null security integration}} - is what's important.
> I found that an ordinary workmanager service contains the following:
> {{https://github.com/wildfly/wildfly/blob/6b61a6003f704221f66dcd9f418bcb7af88fb9ab/connector/src/main/java/org/jboss/as/connector/services/workmanager/WorkManagerService.java#L102}}
> and that the {{securityIntegration}} field is never set for a distributed workmanager in its respective service. I don't know enough of the full picture, but setting the {{securityIntegration}} field for the distributed workmanager as well worked for me - I could submit work without issues.
> Note that the test is using {{standalone-ha.xml}} which seems to have Elytron enabled.
> There might be some concerns about Elytron integration too, but I leave that to [~msimka].
> I am setting the priority to critical, as this doesn't seem to allow users to submit work instances via a distributed workmanager at all.
> Found with commit: 8d587934b771cf91425ea3e06d23dcd7f145e9ef



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 14 07:35:00 2017
From: issues at jboss.org (Marek Schmidt (JIRA))
Date: Tue, 14 Feb 2017 07:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1440) Insufficient
 synchronization in ObjectModelResolverProvider
In-Reply-To: <JIRA.12676625.1487075671000@Atlassian.JIRA>
References: <JIRA.12676625.1487075671000@Atlassian.JIRA>
	<JIRA.12676625.1487075671197@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676625.1487075671000.10892.1487075700238@Atlassian.JIRA>

Marek Schmidt created DROOLS-1440:
-------------------------------------

             Summary: Insufficient synchronization in ObjectModelResolverProvider
                 Key: DROOLS-1440
                 URL: https://issues.jboss.org/browse/DROOLS-1440
             Project: Drools
          Issue Type: Bug
          Components: kie server
    Affects Versions: 6.4.0.Final
         Environment: kie-server 6.4.0.Final-redhat-13 (BPMS 6.3.4)
            Reporter: Marek Schmidt
            Assignee: Edson Tirelli


Immediately after server startup with parallel clients, the following error appeared in the logs, suggesting insufficient synchronization in ObjectModelResolverProvider initialization:

{noformat}
11:59:17,735 WARN  [org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory] (http-10.1.3.249:8080-5) Unable to find ObjectModelResolver for mvel
11:59:17,736 ERROR [org.kie.server.remote.rest.jbpm.ProcessResource] (http-10.1.3.249:8080-5) Unexpected error during processing null: java.lang.NullPointerException
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getInstanceFromModel(DefaultRegisterableItemsFactory.java:213)
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlersFromDescriptor(DefaultRegisterableItemsFactory.java:260)
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlers(DefaultRegisterableItemsFactory.java:84)
	at org.jbpm.runtime.manager.impl.KModuleRegisterableItemsFactory.getWorkItemHandlers(KModuleRegisterableItemsFactory.java:98)
	at org.jbpm.runtime.manager.impl.AbstractRuntimeManager.registerItems(AbstractRuntimeManager.java:119)
	at org.jbpm.runtime.manager.impl.PerProcessInstanceRuntimeManager$PerProcessInstanceInitializer.initKieSession(PerProcessInstanceRuntimeManager.java:514)
	at org.jbpm.runtime.manager.impl.RuntimeEngineImpl.getKieSession(RuntimeEngineImpl.java:70)
	at org.jbpm.kie.services.impl.ProcessServiceImpl.signalProcessInstance(ProcessServiceImpl.java:173)
	at org.kie.server.services.jbpm.ProcessServiceBase.signalProcessInstance(ProcessServiceBase.java:153)
	at org.kie.server.remote.rest.jbpm.ProcessResource.signalProcessInstance(ProcessResource.java:185)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
	at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:583)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:565)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832)
	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620)
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553)
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:482)
	at org.openshift.kieserver.web.redirect.RedirectFilter.doFilter(RedirectFilter.java:150)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.openshift.kieserver.web.security.SecurityFilter.doFilter(SecurityFilter.java:73)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512)
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:656)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]

11:59:17,736 WARN  [org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory] (http-10.1.3.249:8080-1) Unable to find ObjectModelResolver for mvel
11:59:17,738 ERROR [org.kie.server.remote.rest.jbpm.ProcessResource] (http-10.1.3.249:8080-1) Unexpected error during processing null: java.lang.NullPointerException
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getInstanceFromModel(DefaultRegisterableItemsFactory.java:213)
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlersFromDescriptor(DefaultRegisterableItemsFactory.java:260)
	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlers(DefaultRegisterableItemsFactory.java:84)
	at org.jbpm.runtime.manager.impl.KModuleRegisterableItemsFactory.getWorkItemHandlers(KModuleRegisterableItemsFactory.java:98)
	at org.jbpm.runtime.manager.impl.AbstractRuntimeManager.registerItems(AbstractRuntimeManager.java:119)
	at org.jbpm.runtime.manager.impl.PerProcessInstanceRuntimeManager$PerProcessInstanceInitializer.initKieSession(PerProcessInstanceRuntimeManager.java:514)
	at org.jbpm.runtime.manager.impl.RuntimeEngineImpl.getKieSession(RuntimeEngineImpl.java:70)
	at org.jbpm.kie.services.impl.ProcessServiceImpl.signalProcessInstance(ProcessServiceImpl.java:173)
	at org.kie.server.services.jbpm.ProcessServiceBase.signalProcessInstance(ProcessServiceBase.java:153)
	at org.kie.server.remote.rest.jbpm.ProcessResource.signalProcessInstance(ProcessResource.java:185)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
	at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:583)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:565)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832)
	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620)
	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553)
	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:482)
	at org.openshift.kieserver.web.redirect.RedirectFilter.doFilter(RedirectFilter.java:150)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.openshift.kieserver.web.security.SecurityFilter.doFilter(SecurityFilter.java:73)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512)
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:656)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
{noformat}

see https://github.com/droolsjbpm/jbpm/blob/6.4.x/jbpm-runtime-manager/src/main/java/org/jbpm/runtime/manager/impl/DefaultRegisterableItemsFactory.java#L210

and https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.4.x/kie-internal/src/main/java/org/kie/internal/runtime/conf/ObjectModelResolverProvider.java#L37

(seems like resolvers could be an non-null empty array still for the second thread, as it would not go into the synchronized block... )



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 07:36:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8108) Elytron subsystem is unable
 to configure SunPKCS11 provider
In-Reply-To: <JIRA.12676566.1487067271000@Atlassian.JIRA>
References: <JIRA.12676566.1487067271000@Atlassian.JIRA>
	<JIRA.12676566.1487067271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676566.1487067271000.10899.1487075760631@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8108:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Elytron subsystem is unable to configure SunPKCS11 provider
> -----------------------------------------------------------
>
>                 Key: WFLY-8108
>                 URL: https://issues.jboss.org/browse/WFLY-8108
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 11.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.<init>(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 Feb 14 07:43:01 2017
From: issues at jboss.org (Maciej Swiderski (JIRA))
Date: Tue, 14 Feb 2017 07:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1440) Insufficient
 synchronization in ObjectModelResolverProvider
In-Reply-To: <JIRA.12676625.1487075671000@Atlassian.JIRA>
References: <JIRA.12676625.1487075671000@Atlassian.JIRA>
	<JIRA.12676625.1487075671000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676625.1487075671000.11039.1487076181706@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maciej Swiderski reassigned DROOLS-1440:
----------------------------------------

    Assignee: Maciej Swiderski  (was: Edson Tirelli)


> Insufficient synchronization in ObjectModelResolverProvider
> -----------------------------------------------------------
>
>                 Key: DROOLS-1440
>                 URL: https://issues.jboss.org/browse/DROOLS-1440
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.4.0.Final
>         Environment: kie-server 6.4.0.Final-redhat-13 (BPMS 6.3.4)
>            Reporter: Marek Schmidt
>            Assignee: Maciej Swiderski
>
> Immediately after server startup with parallel clients, the following error appeared in the logs, suggesting insufficient synchronization in ObjectModelResolverProvider initialization:
> {noformat}
> 11:59:17,735 WARN  [org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory] (http-10.1.3.249:8080-5) Unable to find ObjectModelResolver for mvel
> 11:59:17,736 ERROR [org.kie.server.remote.rest.jbpm.ProcessResource] (http-10.1.3.249:8080-5) Unexpected error during processing null: java.lang.NullPointerException
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getInstanceFromModel(DefaultRegisterableItemsFactory.java:213)
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlersFromDescriptor(DefaultRegisterableItemsFactory.java:260)
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlers(DefaultRegisterableItemsFactory.java:84)
> 	at org.jbpm.runtime.manager.impl.KModuleRegisterableItemsFactory.getWorkItemHandlers(KModuleRegisterableItemsFactory.java:98)
> 	at org.jbpm.runtime.manager.impl.AbstractRuntimeManager.registerItems(AbstractRuntimeManager.java:119)
> 	at org.jbpm.runtime.manager.impl.PerProcessInstanceRuntimeManager$PerProcessInstanceInitializer.initKieSession(PerProcessInstanceRuntimeManager.java:514)
> 	at org.jbpm.runtime.manager.impl.RuntimeEngineImpl.getKieSession(RuntimeEngineImpl.java:70)
> 	at org.jbpm.kie.services.impl.ProcessServiceImpl.signalProcessInstance(ProcessServiceImpl.java:173)
> 	at org.kie.server.services.jbpm.ProcessServiceBase.signalProcessInstance(ProcessServiceBase.java:153)
> 	at org.kie.server.remote.rest.jbpm.ProcessResource.signalProcessInstance(ProcessResource.java:185)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
> 	at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:583)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:565)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832)
> 	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620)
> 	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553)
> 	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:482)
> 	at org.openshift.kieserver.web.redirect.RedirectFilter.doFilter(RedirectFilter.java:150)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.openshift.kieserver.web.security.SecurityFilter.doFilter(SecurityFilter.java:73)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:656)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> 11:59:17,736 WARN  [org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory] (http-10.1.3.249:8080-1) Unable to find ObjectModelResolver for mvel
> 11:59:17,738 ERROR [org.kie.server.remote.rest.jbpm.ProcessResource] (http-10.1.3.249:8080-1) Unexpected error during processing null: java.lang.NullPointerException
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getInstanceFromModel(DefaultRegisterableItemsFactory.java:213)
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlersFromDescriptor(DefaultRegisterableItemsFactory.java:260)
> 	at org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory.getWorkItemHandlers(DefaultRegisterableItemsFactory.java:84)
> 	at org.jbpm.runtime.manager.impl.KModuleRegisterableItemsFactory.getWorkItemHandlers(KModuleRegisterableItemsFactory.java:98)
> 	at org.jbpm.runtime.manager.impl.AbstractRuntimeManager.registerItems(AbstractRuntimeManager.java:119)
> 	at org.jbpm.runtime.manager.impl.PerProcessInstanceRuntimeManager$PerProcessInstanceInitializer.initKieSession(PerProcessInstanceRuntimeManager.java:514)
> 	at org.jbpm.runtime.manager.impl.RuntimeEngineImpl.getKieSession(RuntimeEngineImpl.java:70)
> 	at org.jbpm.kie.services.impl.ProcessServiceImpl.signalProcessInstance(ProcessServiceImpl.java:173)
> 	at org.kie.server.services.jbpm.ProcessServiceBase.signalProcessInstance(ProcessServiceBase.java:153)
> 	at org.kie.server.remote.rest.jbpm.ProcessResource.signalProcessInstance(ProcessResource.java:185)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_121]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_121]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_121]
> 	at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_121]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:583)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:565)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:130)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832)
> 	at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620)
> 	at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553)
> 	at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:482)
> 	at org.openshift.kieserver.web.redirect.RedirectFilter.doFilter(RedirectFilter.java:150)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.openshift.kieserver.web.security.SecurityFilter.doFilter(SecurityFilter.java:73)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:656)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
> {noformat}
> see https://github.com/droolsjbpm/jbpm/blob/6.4.x/jbpm-runtime-manager/src/main/java/org/jbpm/runtime/manager/impl/DefaultRegisterableItemsFactory.java#L210
> and https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.4.x/kie-internal/src/main/java/org/kie/internal/runtime/conf/ObjectModelResolverProvider.java#L37
> (seems like resolvers could be an non-null empty array still for the second thread, as it would not go into the synchronized block... )



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 07:50:02 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 07:50:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8103) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676517.1487055265000@Atlassian.JIRA>
References: <JIRA.12676517.1487055265000@Atlassian.JIRA>
	<JIRA.12676517.1487055265000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676517.1487055265000.11158.1487076602346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8103:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8103
>                 URL: https://issues.jboss.org/browse/WFLY-8103
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity found 2 occurences of possible null dereference.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359322&mergedDefectId=1395584
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359323&mergedDefectId=1395585
> Method {{resolvePassword()}} is dereferencing {{resolvedPath}} field
> {code}
>     private char[] resolvePassword() throws Exception {
>         ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
>         CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
>         if (cs != null) {
>             return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
>         } else {
>             throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
>         }
>     }
> {code}
> And method {{resolvePassword()}} is called 2 times from block, where resolvedPath is checked on null
> {code}
>     try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
>         AtomicLoadKeyStore.LoadKey loadKey = keyStore.revertibleLoad(is, resolvePassword());
>     try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
>         char[] password = resolvePassword();
> {code}
> Add null check into {{resolvePassword()}} method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 07:51:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8104) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676520.1487056739000@Atlassian.JIRA>
References: <JIRA.12676520.1487056739000@Atlassian.JIRA>
	<JIRA.12676520.1487056739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676520.1487056739000.11200.1487076660664@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8104:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8104
>                 URL: https://issues.jboss.org/browse/WFLY-8104
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity found 2 possible occurences of dereferencing null.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359321&mergedDefectId=1395588
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359320&mergedDefectId=1396462
> {code:java}
>     private char[] resolvePassword() throws Exception {
>         ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
>         CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
>         if (cs != null) {
>             return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
>         } else {
>             throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
>         }
>     }
> {code}
> Both {{getCredential(Class<C> credentialType)}} and {{getPassword(Class<P> type)}} have in javadoc mentioned return value can be null.
> Also in org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder.SimpleDirContextFactory.obtainDirContext(org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode) returned value are explicitely checked on null value.
> Add null check also in {{resolvePassword()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 07:51:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 07:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8106) Coverity static analysis,
 Dereference null return value,
 CredentialStoreAliasDefinition (elytron-subsystem)
In-Reply-To: <JIRA.12676545.1487060850000@Atlassian.JIRA>
References: <JIRA.12676545.1487060850000@Atlassian.JIRA>
	<JIRA.12676545.1487060850000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676545.1487060850000.11227.1487076661429@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8106:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Dereference null return value, CredentialStoreAliasDefinition (elytron-subsystem) 
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8106
>                 URL: https://issues.jboss.org/browse/WFLY-8106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity found 2 possible occurences of dereferencing null. Method {{propertyAliasFromOperation(final ModelNode operation)}} can return null.
> And return value of {{propertyAliasFromOperation(final ModelNode operation)}} is dereferenced in {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}}
> {code:java}
>     private static void transformOperationAddress(final ModelNode operation) {
>         Property alias = propertyAliasFromOperation(operation);
>         String newAlias = alias.getValue().asString().toLowerCase(Locale.ROOT);
>         alias.getValue().set(newAlias);
>     }
>     private static boolean sameAlias(final OperationContext context, final ModelNode operation) {
>         String contextAlias = context.getCurrentAddress().getLastElement().getValue();
>         String operationAlias = propertyAliasFromOperation(operation).getValue().asString();
>         return  operationAlias.equals(contextAlias);
>     }
>     private static Property propertyAliasFromOperation(final ModelNode operation) {
>         ModelNode address = operation.get(ModelDescriptionConstants.OP_ADDR);
>         List<Property> list = address.asPropertyList();
>         Property alias = null;
>         for (Property p: list) {
>             if (ElytronDescriptionConstants.ALIAS.equals(p.getName())) {
>                 alias = p;
>                 break;
>             }
>         }
>         return alias;
>     }
> {code}
> Add null check into {{transformOperationAddress(final ModelNode operation)}} and {{sameAlias(final OperationContext context, final ModelNode operation)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 07:52:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 07:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8107) Coverity static analysis,
 Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
In-Reply-To: <JIRA.12676552.1487061917000@Atlassian.JIRA>
References: <JIRA.12676552.1487061917000@Atlassian.JIRA>
	<JIRA.12676552.1487061917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676552.1487061917000.11260.1487076721289@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8107:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-8107
>                 URL: https://issues.jboss.org/browse/WFLY-8107
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.
> {code:java}
>     private X509Certificate getClientCertificate() throws SaslException {
>         if ((clientCertChain != null) && (clientCertChain.length > 0)) {
>             return clientCertChain[0];
>         } else if (clientCertUrl != null) {
>             try {
>                 return EntityUtil.getCertificateFromUrl(clientCertUrl);
>             } catch (IOException e) {
>                 throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
>             }
>         } else {
>             throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 08:12:00 2017
From: issues at jboss.org (Lin Gao (JIRA))
Date: Tue, 14 Feb 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8111) Upgrade picketlink 2.5.5.SP4
	to 2.5.5.SP5
In-Reply-To: <JIRA.12676657.1487077881000@Atlassian.JIRA>
References: <JIRA.12676657.1487077881000@Atlassian.JIRA>
	<JIRA.12676657.1487077881046@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676657.1487077881000.11406.1487077920219@Atlassian.JIRA>

Lin Gao created WFLY-8111:
-----------------------------

             Summary: Upgrade picketlink 2.5.5.SP4 to 2.5.5.SP5
                 Key: WFLY-8111
                 URL: https://issues.jboss.org/browse/WFLY-8111
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Lin Gao
            Assignee: Kabir Khan






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 08:24:00 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Tue, 14 Feb 2017 08:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-916) Add ability to use specified
 Provider[] when creating KeyStore instance in KeyStoreCredentialStore
In-Reply-To: <JIRA.12674788.1486127142000@Atlassian.JIRA>
References: <JIRA.12674788.1486127142000@Atlassian.JIRA>
	<JIRA.12674788.1486127142000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674788.1486127142000.11488.1487078640434@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek reopened ELY-916:
------------------------------


There are missing API changes.

> Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore
> --------------------------------------------------------------------------------------------------
>
>                 Key: ELY-916
>                 URL: https://issues.jboss.org/browse/ELY-916
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Credential Store
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: 1.1.0.Beta23
>
>
> Add ability to use specified Provider[] when creating KeyStore instance in KeyStoreCredentialStore.
> This will give us opportunity to use custom KeyStore (for example for FIPS certified CredentialStore).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 08:45:02 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 14 Feb 2017 08:45:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8112) Elytron subsystem is unable
 to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode
In-Reply-To: <JIRA.12676665.1487079899000@Atlassian.JIRA>
References: <JIRA.12676665.1487079899000@Atlassian.JIRA>
	<JIRA.12676665.1487079899254@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676665.1487079899000.11669.1487079902331@Atlassian.JIRA>

Martin Choma created WFLY-8112:
----------------------------------

             Summary: Elytron subsystem is unable to configure com.sun.net.ssl.internal.ssl.Provider in FIPS mode
                 Key: WFLY-8112
                 URL: https://issues.jboss.org/browse/WFLY-8112
             Project: WildFly
          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 Feb 14 09:46:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 14 Feb 2017 09:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure
 link from CloudForms to MW Provider
In-Reply-To: <JIRA.12676682.1487083546000@Atlassian.JIRA>
References: <JIRA.12676682.1487083546000@Atlassian.JIRA>
	<JIRA.12676682.1487083546645@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676682.1487083546000.12333.1487083561394@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-33:
----------------------------------------

             Summary: [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: mfoley user
            Priority: Critical


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 Feb 14 09:47:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 14 Feb 2017 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-34) Automation Testcase
In-Reply-To: <JIRA.12676683.1487083606000@Atlassian.JIRA>
References: <JIRA.12676683.1487083606000@Atlassian.JIRA>
	<JIRA.12676683.1487083606361@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676683.1487083606000.12345.1487083620510@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-34:
----------------------------------------

             Summary: Automation Testcase
                 Key: HAWKULARQE-34
                 URL: https://issues.jboss.org/browse/HAWKULARQE-34
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user
            Priority: Critical


Smoke automation test to add new middleware provider with SSL and check that inventory is loaded.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 09:48:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 14 Feb 2017 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-35) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12676684.1487083677000@Atlassian.JIRA>
References: <JIRA.12676684.1487083677000@Atlassian.JIRA>
	<JIRA.12676684.1487083677563@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676684.1487083677000.12358.1487083680701@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-35:
----------------------------------------

             Summary: 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: mfoley user
            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  Tue Feb 14 09:49:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Tue, 14 Feb 2017 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-36) IPV6
In-Reply-To: <JIRA.12676685.1487083694000@Atlassian.JIRA>
References: <JIRA.12676685.1487083694000@Atlassian.JIRA>
	<JIRA.12676685.1487083694517@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676685.1487083694000.12368.1487083740888@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-36:
--------------------------------------

             Summary: IPV6
                 Key: HAWKULARQE-36
                 URL: https://issues.jboss.org/browse/HAWKULARQE-36
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Matt Mahoney
            Assignee: mfoley user


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  Tue Feb 14 10:18:00 2017
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Tue, 14 Feb 2017 10:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-976) Deployment fails with
 missing/unavailable dependencies
In-Reply-To: <JIRA.12564686.1425386008000@Atlassian.JIRA>
References: <JIRA.12564686.1425386008000@Atlassian.JIRA>
	<JIRA.12564686.1425386008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564686.1425386008000.13233.1487085480917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved WFCORE-976.
-----------------------------------
    Resolution: Out of Date


> Deployment fails with missing/unavailable dependencies
> ------------------------------------------------------
>
>                 Key: WFCORE-976
>                 URL: https://issues.jboss.org/browse/WFCORE-976
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> Our testsuite bootstraps the server and then waits for the native management interface to become available on 8181
> A subsequent deployment (intermittently) fails with 
> {code}
> domain-master> [Host Controller] [0m[0m05:09:40,678 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /opt/jboss/wildfly/domain/data/content/ef/3743938a6b38a2ae473f12778fef7ad0ce464c/content[0m
> domain-slave> [Server:server-one] [0m[31m05:09:41,654 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 5) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "domain-endpoint.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"domain-endpoint.war\" is missing [jboss.deployment.chains]"]}[0m
> {code}
> There seems to be a missing guarantee that allows the management endpoint to answer deployment requests when the deployment chain services are not up.
> CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/175



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:31:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 10:31:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2295)
 org.jboss.as.domain-management does not permit non-JKS file keystore
In-Reply-To: <JIRA.12676705.1487086235000@Atlassian.JIRA>
References: <JIRA.12676705.1487086235000@Atlassian.JIRA>
	<JIRA.12676705.1487086235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676705.1487086235000.13518.1487086264258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-8829 to WFCORE-2295:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2295  (was: JBEAP-8829)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s:     (was: 6.4.0.GA)


> org.jboss.as.domain-management does not permit non-JKS file keystore
> --------------------------------------------------------------------
>
>                 Key: WFCORE-2295
>                 URL: https://issues.jboss.org/browse/WFCORE-2295
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: Java 1.8.0_121, EAP 6.4.13
>            Reporter: Rich Lucente
>            Assignee: Brian Stansberry
>              Labels: eap, fips, management, security
>         Attachments: ProviderFileKeyManagerService.java, ProviderFileKeystore.java, ProviderFileTrustManagerService.java, SecurityRealmAddHandler.java
>
>
> org.jboss.as.domain-management subsystem only enables users to specify either a `provider` attribute or a `keystore-path` attribute but not both.  Users wishing to use a FIPS 140-2 certified provider are limited to the SunPKCS11 provider on RHEL.  Non-JKS JCE providers that require an alternative provider with a keystore-path cannot be configured to secure the management interface.
> With the recent FIPS 140-2 certification of pure java open source cryptographic modules, government customers seek to secure EAP on multiple operating systems using FIPS certified JCE providers.  These same customers must use common criteria certified software and follow DISA security technical implementation guidelines (http://iase.disa.mil/stigs/app-security/app-servers/Pages/jboss.aspx).  Currently, EAP 6 is the only option to meet both of those conditions.
> The attached files incorporate changes to the org.jboss.as.domain.management.security package to enable the use of file-based keystores that rely on alternative JCE providers and that do not use JKS formatted keystores.
> This configuration with the bouncy castle pure java FIPS 140-2 certified provider and the attached software changes enable securing the management interface:
> {noformat}
>             ...
>             <security-realm name="ManagementRealmHTTPS">
>                 <server-identities>
>                     <ssl protocol="TLS">
>                         <engine enabled-cipher-suites="SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA" enabled-protocols="TLSv1 TLSv1.1 TLSv1.2"/>
>                         <keystore provider="BCFKS" path="vault/vault.bcfks" relative-to="jboss.home.dir" keystore-password="admin1jboss_" alias="jbossweb" key-password="admin1jboss_"/>
>                     </ssl>
>                 </server-identities>
>                 <authentication>
>                     <properties path="https-mgmt-users.properties" relative-to="jboss.server.config.dir"/>
>                 </authentication>
>             </security-realm>
>             ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:32:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 10:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2295)
 org.jboss.as.domain-management does not permit non-JKS file keystore
In-Reply-To: <JIRA.12676705.1487086235000@Atlassian.JIRA>
References: <JIRA.12676705.1487086235000@Atlassian.JIRA>
	<JIRA.12676705.1487086235000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676705.1487086235000.13527.1487086320418@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2295:
-------------------------------------
    Component/s: Security


> org.jboss.as.domain-management does not permit non-JKS file keystore
> --------------------------------------------------------------------
>
>                 Key: WFCORE-2295
>                 URL: https://issues.jboss.org/browse/WFCORE-2295
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>         Environment: Java 1.8.0_121, EAP 6.4.13
>            Reporter: Rich Lucente
>            Assignee: Brian Stansberry
>              Labels: eap, fips, management, security
>         Attachments: ProviderFileKeyManagerService.java, ProviderFileKeystore.java, ProviderFileTrustManagerService.java, SecurityRealmAddHandler.java
>
>
> org.jboss.as.domain-management subsystem only enables users to specify either a `provider` attribute or a `keystore-path` attribute but not both.  Users wishing to use a FIPS 140-2 certified provider are limited to the SunPKCS11 provider on RHEL.  Non-JKS JCE providers that require an alternative provider with a keystore-path cannot be configured to secure the management interface.
> With the recent FIPS 140-2 certification of pure java open source cryptographic modules, government customers seek to secure EAP on multiple operating systems using FIPS certified JCE providers.  These same customers must use common criteria certified software and follow DISA security technical implementation guidelines (http://iase.disa.mil/stigs/app-security/app-servers/Pages/jboss.aspx).  Currently, EAP 6 is the only option to meet both of those conditions.
> The attached files incorporate changes to the org.jboss.as.domain.management.security package to enable the use of file-based keystores that rely on alternative JCE providers and that do not use JKS formatted keystores.
> This configuration with the bouncy castle pure java FIPS 140-2 certified provider and the attached software changes enable securing the management interface:
> {noformat}
>             ...
>             <security-realm name="ManagementRealmHTTPS">
>                 <server-identities>
>                     <ssl protocol="TLS">
>                         <engine enabled-cipher-suites="SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA" enabled-protocols="TLSv1 TLSv1.1 TLSv1.2"/>
>                         <keystore provider="BCFKS" path="vault/vault.bcfks" relative-to="jboss.home.dir" keystore-password="admin1jboss_" alias="jbossweb" key-password="admin1jboss_"/>
>                     </ssl>
>                 </server-identities>
>                 <authentication>
>                     <properties path="https-mgmt-users.properties" relative-to="jboss.server.config.dir"/>
>                 </authentication>
>             </security-realm>
>             ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:36:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 14 Feb 2017 10:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8113) Upgrade netty-xnio-transport
 to 0.1.2.Final
In-Reply-To: <JIRA.12676708.1487086529000@Atlassian.JIRA>
References: <JIRA.12676708.1487086529000@Atlassian.JIRA>
	<JIRA.12676708.1487086529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676708.1487086529000.13570.1487086560910@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8830 to WFLY-8113:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8113  (was: JBEAP-8830)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: ActiveMQ)
                     (was: JMS)


> Upgrade netty-xnio-transport to 0.1.2.Final
> -------------------------------------------
>
>                 Key: WFLY-8113
>                 URL: https://issues.jboss.org/browse/WFLY-8113
>             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  Tue Feb 14 10:39:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-947) Add our own syslog
	implementation
In-Reply-To: <JIRA.12676709.1487086700000@Atlassian.JIRA>
References: <JIRA.12676709.1487086700000@Atlassian.JIRA>
	<JIRA.12676709.1487086700370@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676709.1487086700000.13604.1487086741103@Atlassian.JIRA>

Darran Lofthouse created ELY-947:
------------------------------------

             Summary: Add our own syslog implementation
                 Key: ELY-947
                 URL: https://issues.jboss.org/browse/ELY-947
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: Audit
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta26






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:39:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events
In-Reply-To: <JIRA.12676710.1487086731000@Atlassian.JIRA>
References: <JIRA.12676710.1487086731000@Atlassian.JIRA>
	<JIRA.12676710.1487086731213@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676710.1487086731000.13616.1487086741490@Atlassian.JIRA>

Darran Lofthouse created ELY-948:
------------------------------------

             Summary: 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.Beta25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:40:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign
 priorities to audit events
In-Reply-To: <JIRA.12676711.1487086785000@Atlassian.JIRA>
References: <JIRA.12676711.1487086785000@Atlassian.JIRA>
	<JIRA.12676711.1487086785293@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676711.1487086785000.13628.1487086800600@Atlassian.JIRA>

Darran Lofthouse created ELY-949:
------------------------------------

             Summary: 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.Beta25


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  Tue Feb 14 10:41:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation
In-Reply-To: <JIRA.12676712.1487086826000@Atlassian.JIRA>
References: <JIRA.12676712.1487086826000@Atlassian.JIRA>
	<JIRA.12676712.1487086826746@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676712.1487086826000.13631.1487086860160@Atlassian.JIRA>

Darran Lofthouse created ELY-950:
------------------------------------

             Summary: 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.Beta25


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  Tue Feb 14 10:42:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues
In-Reply-To: <JIRA.12676713.1487086905000@Atlassian.JIRA>
References: <JIRA.12676713.1487086905000@Atlassian.JIRA>
	<JIRA.12676713.1487086905498@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676713.1487086905000.13646.1487086920881@Atlassian.JIRA>

Darran Lofthouse created ELY-951:
------------------------------------

             Summary: 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.Beta25


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  Tue Feb 14 10:43:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:43:00 -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: <JIRA.12676714.1487086965000@Atlassian.JIRA>
References: <JIRA.12676714.1487086965000@Atlassian.JIRA>
	<JIRA.12676714.1487086965792@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676714.1487086965000.13666.1487086980656@Atlassian.JIRA>

Darran Lofthouse created ELY-952:
------------------------------------

             Summary: 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.Beta25


Presently events could be dropped.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 10:50:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 10:50:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-953) Release WildFly Elytron
	1.1.0.Beta25
In-Reply-To: <JIRA.12676718.1487087392000@Atlassian.JIRA>
References: <JIRA.12676718.1487087392000@Atlassian.JIRA>
	<JIRA.12676718.1487087392404@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676718.1487087392000.13768.1487087401927@Atlassian.JIRA>

Darran Lofthouse created ELY-953:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta25
                 Key: ELY-953
                 URL: https://issues.jboss.org/browse/ELY-953
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta25






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:27:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 14 Feb 2017 11:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8050) Upgrade Artemis to 1.5.3
In-Reply-To: <JIRA.12675334.1486480967000@Atlassian.JIRA>
References: <JIRA.12675334.1486480967000@Atlassian.JIRA>
	<JIRA.12675334.1486480967000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675334.1486480967000.14137.1487089620588@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-8050:
------------------------------
    Summary: Upgrade Artemis to 1.5.3  (was: Upgrade Artemis to 1.5.1.jbossorg-002)


> Upgrade Artemis to 1.5.3
> ------------------------
>
>                 Key: WFLY-8050
>                 URL: https://issues.jboss.org/browse/WFLY-8050
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> (note that it might be possible that we upgrade to Artemis upstream 1.5.3 instead of 1.5.1.jbossorg-002).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:38:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 14 Feb 2017 11:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from
 Tech Preview release to CFME 4.5 release
In-Reply-To: <JIRA.12675308.1486476804000@Atlassian.JIRA>
References: <JIRA.12675308.1486476804000@Atlassian.JIRA>
	<JIRA.12675308.1486476804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675308.1486476804000.14247.1487090280858@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363342#comment-13363342 ] 

Hayk Hovsepyan commented on HAWKULARQE-30:
------------------------------------------

Upgraded Hawkular Services docker container,
provider Timelines are kept, 

> [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  Tue Feb 14 11:51:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 11:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-954) Coverity static analysis,
 Dereference null return value, OAuth2CredentialSource (Elytron)
In-Reply-To: <JIRA.12676249.1486990586000@Atlassian.JIRA>
References: <JIRA.12676249.1486990586000@Atlassian.JIRA>
	<JIRA.12676249.1486990586000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676249.1486990586000.14376.1487091060293@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-8095 to ELY-954:
-----------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-954  (was: WFLY-8095)
    Component/s: Credential Store
                     (was: Security)


> Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-954
>                 URL: https://issues.jboss.org/browse/ELY-954
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> Coverity found possible dereferencing of null value returned from {{resolveSSLContext()}} in {{openConnection()}}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564099&defectInstanceId=2359300&mergedDefectId=1389514
> {code:java|title=OAuth2CredentialSource.java}
>     private SSLContext resolveSSLContext() {
>         if (!isHttps(tokenEndpointUri)) {
>             return null;
>         }
>         return sslContextSupplier == null ? null : sslContextSupplier.get();
>     }
>     private HttpURLConnection openConnection() throws IOException {
>         log.debugf("Opening connection to [%s]", tokenEndpointUri);
>         HttpURLConnection connection = (HttpURLConnection) tokenEndpointUri.openConnection();
>         if (isHttps(tokenEndpointUri)) {
>             HttpsURLConnection https = (HttpsURLConnection) connection;
>             https.setSSLSocketFactory(resolveSSLContext().getSocketFactory());
>             if (hostnameVerifierSupplier != null) {
>                 https.setHostnameVerifier(checkNotNullParam("hostnameVerifier", hostnameVerifierSupplier.get()));
>             }
>         }
>         return connection;
>     }
> {code}
> NPE could probably happen if {{oauth2-introspection}} is configured with no {{client-ssl-context}} and https {{introspection-url}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:51:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 11:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-954) Coverity static analysis,
 Dereference null return value, OAuth2CredentialSource (Elytron)
In-Reply-To: <JIRA.12676249.1486990586000@Atlassian.JIRA>
References: <JIRA.12676249.1486990586000@Atlassian.JIRA>
	<JIRA.12676249.1486990586000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676249.1486990586000.14380.1487091060463@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-954:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-954
>                 URL: https://issues.jboss.org/browse/ELY-954
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>
> Coverity found possible dereferencing of null value returned from {{resolveSSLContext()}} in {{openConnection()}}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564099&defectInstanceId=2359300&mergedDefectId=1389514
> {code:java|title=OAuth2CredentialSource.java}
>     private SSLContext resolveSSLContext() {
>         if (!isHttps(tokenEndpointUri)) {
>             return null;
>         }
>         return sslContextSupplier == null ? null : sslContextSupplier.get();
>     }
>     private HttpURLConnection openConnection() throws IOException {
>         log.debugf("Opening connection to [%s]", tokenEndpointUri);
>         HttpURLConnection connection = (HttpURLConnection) tokenEndpointUri.openConnection();
>         if (isHttps(tokenEndpointUri)) {
>             HttpsURLConnection https = (HttpsURLConnection) connection;
>             https.setSSLSocketFactory(resolveSSLContext().getSocketFactory());
>             if (hostnameVerifierSupplier != null) {
>                 https.setHostnameVerifier(checkNotNullParam("hostnameVerifier", hostnameVerifierSupplier.get()));
>             }
>         }
>         return connection;
>     }
> {code}
> NPE could probably happen if {{oauth2-introspection}} is configured with no {{client-ssl-context}} and https {{introspection-url}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:57:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 14 Feb 2017 11:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1441) Nested accumulate makes DRL
 twice as slow in statefull session
In-Reply-To: <JIRA.12676769.1487091368000@Atlassian.JIRA>
References: <JIRA.12676769.1487091368000@Atlassian.JIRA>
	<JIRA.12676769.1487091368537@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676769.1487091368000.14459.1487091420782@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-1441:
----------------------------------------

             Summary: Nested accumulate makes DRL twice as slow in statefull session
                 Key: DROOLS-1441
                 URL: https://issues.jboss.org/browse/DROOLS-1441
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.Beta6
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco
         Attachments: Selection_350.png





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:57:01 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 14 Feb 2017 11:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1441) Nested accumulate makes DRL
 twice as slow in statefull session
In-Reply-To: <JIRA.12676769.1487091369000@Atlassian.JIRA>
References: <JIRA.12676769.1487091369000@Atlassian.JIRA>
	<JIRA.12676769.1487091369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676769.1487091369000.14469.1487091421094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1441:
-------------------------------------
    Attachment: Selection_350.png


> Nested accumulate makes DRL twice as slow in statefull session
> --------------------------------------------------------------
>
>                 Key: DROOLS-1441
>                 URL: https://issues.jboss.org/browse/DROOLS-1441
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_350.png
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 11:58:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 14 Feb 2017 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1441) Nested accumulate makes DRL
 twice as slow in statefull session
In-Reply-To: <JIRA.12676769.1487091369000@Atlassian.JIRA>
References: <JIRA.12676769.1487091369000@Atlassian.JIRA>
	<JIRA.12676769.1487091369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676769.1487091369000.14476.1487091480346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1441:
-------------------------------------
    Description: 
To reproduce: comment out to replace the 2 rules in this DRL:
  https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-examples/src/main/resources/org/optaplanner/examples/tennis/solver/tennisScoreRules.drl
and run TennisApp


> Nested accumulate makes DRL twice as slow in statefull session
> --------------------------------------------------------------
>
>                 Key: DROOLS-1441
>                 URL: https://issues.jboss.org/browse/DROOLS-1441
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_350.png
>
>
> To reproduce: comment out to replace the 2 rules in this DRL:
>   https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-examples/src/main/resources/org/optaplanner/examples/tennis/solver/tennisScoreRules.drl
> and run TennisApp



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:06:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 14 Feb 2017 12:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-912) Create DirContext is not able
 to log arrays correctly
In-Reply-To: <JIRA.12674726.1486114827000@Atlassian.JIRA>
References: <JIRA.12674726.1486114827000@Atlassian.JIRA>
	<JIRA.12674726.1486114827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674726.1486114827000.14563.1487091960519@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-912:
------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> 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
>
> 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  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-953) Release WildFly Elytron
	1.1.0.Beta25
In-Reply-To: <JIRA.12676718.1487087392000@Atlassian.JIRA>
References: <JIRA.12676718.1487087392000@Atlassian.JIRA>
	<JIRA.12676718.1487087392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676718.1487087392000.14589.1487092083490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-953.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta25
> ------------------------------------
>
>                 Key: ELY-953
>                 URL: https://issues.jboss.org/browse/ELY-953
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta25
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues
In-Reply-To: <JIRA.12676713.1487086905000@Atlassian.JIRA>
References: <JIRA.12676713.1487086905000@Atlassian.JIRA>
	<JIRA.12676713.1487086905000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676713.1487086905000.14595.1487092083611@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation
In-Reply-To: <JIRA.12676712.1487086827000@Atlassian.JIRA>
References: <JIRA.12676712.1487086827000@Atlassian.JIRA>
	<JIRA.12676712.1487086827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676712.1487086827000.14598.1487092083715@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign
 priorities to audit events
In-Reply-To: <JIRA.12676711.1487086785000@Atlassian.JIRA>
References: <JIRA.12676711.1487086785000@Atlassian.JIRA>
	<JIRA.12676711.1487086785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676711.1487086785000.14601.1487092083867@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events
In-Reply-To: <JIRA.12676710.1487086731000@Atlassian.JIRA>
References: <JIRA.12676710.1487086731000@Atlassian.JIRA>
	<JIRA.12676710.1487086731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676710.1487086731000.14604.1487092083963@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12676714.1487086966000@Atlassian.JIRA>
References: <JIRA.12676714.1487086966000@Atlassian.JIRA>
	<JIRA.12676714.1487086966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676714.1487086966000.14592.1487092083553@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> Presently events could be dropped.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication
 client has no trust configuration
In-Reply-To: <JIRA.12675878.1486694187000@Atlassian.JIRA>
References: <JIRA.12675878.1486694187000@Atlassian.JIRA>
	<JIRA.12675878.1486694187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675878.1486694187000.14616.1487092084358@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within
	HTTP API
In-Reply-To: <JIRA.12676078.1486812681000@Atlassian.JIRA>
References: <JIRA.12676078.1486812681000@Atlassian.JIRA>
	<JIRA.12676078.1486812681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676078.1486812681000.14607.1487092084031@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication
 client should not mandate an input source
In-Reply-To: <JIRA.12675879.1486694444000@Atlassian.JIRA>
References: <JIRA.12675879.1486694444000@Atlassian.JIRA>
	<JIRA.12675879.1486694444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675879.1486694444000.14613.1487092084300@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.14622.1487092084551@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of
 CLIENT_CERT authentication for SASL
In-Reply-To: <JIRA.12675877.1486693276000@Atlassian.JIRA>
References: <JIRA.12675877.1486693276000@Atlassian.JIRA>
	<JIRA.12675877.1486693276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675877.1486693276000.14619.1487092084479@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.14625.1487092084621@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.14629.1487092084709@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.0.0.Beta26
                       (was: 1.1.0.Beta25)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.0.0.Beta26
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support
 standard KeyManager instances
In-Reply-To: <JIRA.12675881.1486695345000@Atlassian.JIRA>
References: <JIRA.12675881.1486695345000@Atlassian.JIRA>
	<JIRA.12675881.1486695345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675881.1486695345000.14610.1487092084105@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.14632.1487092084845@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.14638.1487092085171@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.14641.1487092085284@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.14635.1487092084965@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.14645.1487092085372@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.14648.1487092085510@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.14651.1487092085575@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.14654.1487092085635@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.14659.1487092085808@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.14663.1487092085934@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.14666.1487092086016@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.14670.1487092086133@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.14674.1487092086258@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.14677.1487092086322@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.14680.1487092086459@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.14683.1487092086564@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.14687.1487092086666@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.14690.1487092086822@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.14694.1487092086929@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.14697.1487092086995@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.14700.1487092087060@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.14704.1487092087149@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.14707.1487092087242@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.14710.1487092087446@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.14714.1487092087526@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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
>             Fix For: 1.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.14717.1487092087587@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.14721.1487092087703@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.14726.1487092087852@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.14732.1487092088009@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.14738.1487092088171@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.14729.1487092087905@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.14742.1487092088254@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the
 'org.wildfly.security.mechanism' package and sub packages.
In-Reply-To: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.14748.1487092088382@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.14745.1487092088305@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.14735.1487092088112@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.14757.1487092088613@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the
 'org.wildfly.security.credential' package and sub packages.
In-Reply-To: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.14751.1487092088452@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.14762.1487092088746@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.14765.1487092088864@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08: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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.14754.1487092088559@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:08:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.14772.1487092089030@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> 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  Tue Feb 14 12:08:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.14769.1487092088979@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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  Tue Feb 14 12:08:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:08:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.14775.1487092089107@Atlassian.JIRA>


     [ 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.0.0.Beta26
                       (was: 1.1.0.Beta25)


> 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.0.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:12:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2296) Upgrade to WildFly Elytron
	1.1.0.Beta25
In-Reply-To: <JIRA.12676792.1487092307000@Atlassian.JIRA>
References: <JIRA.12676792.1487092307000@Atlassian.JIRA>
	<JIRA.12676792.1487092307916@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676792.1487092307000.14821.1487092320361@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2296:
----------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta25
                 Key: WFCORE-2296
                 URL: https://issues.jboss.org/browse/WFCORE-2296
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta1






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:14:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 12:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2297) Upgrade Elytron Web to
	1.0.0.Beta10
In-Reply-To: <JIRA.12676793.1487092383000@Atlassian.JIRA>
References: <JIRA.12676793.1487092383000@Atlassian.JIRA>
	<JIRA.12676793.1487092383113@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676793.1487092383000.14839.1487092440564@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2297:
----------------------------------------

             Summary: Upgrade Elytron Web to 1.0.0.Beta10
                 Key: WFCORE-2297
                 URL: https://issues.jboss.org/browse/WFCORE-2297
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta1






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:22:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-955) Coverity static analysis:
 Dereference null return value in ServerAuthenticationContext (Elytron)
In-Reply-To: <JIRA.12672987.1485348828000@Atlassian.JIRA>
References: <JIRA.12672987.1485348828000@Atlassian.JIRA>
	<JIRA.12672987.1485348828000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672987.1485348828000.14893.1487092920109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7965 to ELY-955:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-955  (was: WFLY-7965)
          Component/s: Authentication Mechanisms
                           (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)
> ------------------------------------------------------------------------------------------------
>
>                 Key: ELY-955
>                 URL: https://issues.jboss.org/browse/ELY-955
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity static-analysis scan found possible dereference null return value in following code
> {code:java|title=ServerAuthenticationContext.java}
> if (log.isTraceEnabled()) {
>                 log.tracef("Authorizing principal %s.", authenticationPrincipal.getName());
>                 log.tracef("Authorizing against the following attributes: %s => %s",
>                         authorizationIdentity.getAttributes().keySet(), authorizationIdentity.getAttributes().values());
>             }
> {code}
> Coverity suppose null value could get here via {{AggregateSecurityRealm.Identity.getAuthorizationIdentity}} calling {{TokenSecurityRealm.TokenRealmIdentity.getAuthorizationIdentity}}
> {code:java|title=TokenRealmIdentity.java}
>         @Override
>         public AuthorizationIdentity getAuthorizationIdentity() throws RealmUnavailableException {
>             if (exists()) {
>                 return new AuthorizationIdentity() {
>                     @Override
>                     public Attributes getAttributes() {
>                         return claims;
>                     }
>                 };
>             }
>             return null;
>         }
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553790&defectInstanceId=2139010&mergedDefectId=1397421&eventId=2139010-2



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:24:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 14 Feb 2017 12:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from
 Tech Preview release to CFME 4.5 release
In-Reply-To: <JIRA.12675308.1486476804000@Atlassian.JIRA>
References: <JIRA.12675308.1486476804000@Atlassian.JIRA>
	<JIRA.12675308.1486476804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675308.1486476804000.14898.1487093040367@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363381#comment-13363381 ] 

Hayk Hovsepyan commented on HAWKULARQE-30:
------------------------------------------

Upgraded C* container: provider Timelines are kept, but server Local Capacity & Utilization (metrics) is lost.

> [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  Tue Feb 14 12:26:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:26:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-956) Coverity static analysis:
 Synchronization on java.util.concurrent object in
 ElytronPolicyConfigurationFactory
In-Reply-To: <JIRA.12672827.1485264437000@Atlassian.JIRA>
References: <JIRA.12672827.1485264437000@Atlassian.JIRA>
	<JIRA.12672827.1485264437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672827.1485264437000.14933.1487093161094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7952 to ELY-956:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-956  (was: WFLY-7952)
          Component/s:     (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> 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  Tue Feb 14 12:41:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 14 Feb 2017 12:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7093) Transfer of contextData back
 to the jboss ejb client
In-Reply-To: <JIRA.12649780.1473690854000@Atlassian.JIRA>
References: <JIRA.12649780.1473690854000@Atlassian.JIRA>
	<JIRA.12649780.1473690854000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649780.1473690854000.15003.1487094060791@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-7093:
-------------------------------
    Attachment: MethodInvocationResponseHandler.java.diff


> Transfer of contextData back to the jboss ejb client
> ----------------------------------------------------
>
>                 Key: WFLY-7093
>                 URL: https://issues.jboss.org/browse/WFLY-7093
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: David Lloyd
>            Priority: Minor
>         Attachments: MethodInvocationMessageHandler.java.diff, MethodInvocationResponseHandler.java.diff
>
>
> The spec says:
> The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation.
> The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:41:01 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 14 Feb 2017 12:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7093) Transfer of contextData back
 to the jboss ejb client
In-Reply-To: <JIRA.12649780.1473690854000@Atlassian.JIRA>
References: <JIRA.12649780.1473690854000@Atlassian.JIRA>
	<JIRA.12649780.1473690854000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649780.1473690854000.15034.1487094061551@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-7093:
-------------------------------
    Attachment: MethodInvocationMessageHandler.java.diff


> Transfer of contextData back to the jboss ejb client
> ----------------------------------------------------
>
>                 Key: WFLY-7093
>                 URL: https://issues.jboss.org/browse/WFLY-7093
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: David Lloyd
>            Priority: Minor
>         Attachments: MethodInvocationMessageHandler.java.diff, MethodInvocationResponseHandler.java.diff
>
>
> The spec says:
> The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation.
> The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:47:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis:
 DefaultSingleSignOn.getIdentity() not synchronized
In-Reply-To: <JIRA.12672942.1485334161000@Atlassian.JIRA>
References: <JIRA.12672942.1485334161000@Atlassian.JIRA>
	<JIRA.12672942.1485334161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672942.1485334161000.15045.1487094420206@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7959 to ELY-957:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-957  (was: WFLY-7959)
          Component/s: HTTP
                           (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> 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: Ilia Vassilev
>            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  Tue Feb 14 12:52:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-958) Coverity static analysis:
 Dereference null return value in KeyUtil (Elytron)
In-Reply-To: <JIRA.12672946.1485334355000@Atlassian.JIRA>
References: <JIRA.12672946.1485334355000@Atlassian.JIRA>
	<JIRA.12672946.1485334355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672946.1485334355000.15072.1487094720265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7960 to ELY-958:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-958  (was: WFLY-7960)
          Component/s:     (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> Coverity static analysis: Dereference null return value in KeyUtil (Elytron)
> ----------------------------------------------------------------------------
>
>                 Key: ELY-958
>                 URL: https://issues.jboss.org/browse/ELY-958
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity static analysis found possible use of null object comming from {{RawPBEKey.getSalt()}} passed into {{javax.crypto.spec.PBEParameterSpec.PBEParameterSpec}}
> {code:java|title=javax.crypto.spec.PBEParameterSpec.java}
> public PBEParameterSpec(byte[] salt, int iterationCount) {
>     this.salt = salt.clone();
>     this.iterationCount = iterationCount;
> }
> {code}
> Responsible elytron code:
> {code:java|title=KeyUtils.java}
> if (key instanceof PBEKey && paramSpecClass.isAssignableFrom(PBEParameterSpec.class)) {
>             final PBEKey pbeKey = (PBEKey) key;
>             // TODO: we miss the IV here
>             return paramSpecClass.cast(new PBEParameterSpec(pbeKey.getSalt(), pbeKey.getIterationCount()));
>         }
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490615&defectInstanceId=2123254&mergedDefectId=1389515



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:54:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-959) Coverity static analysis:
 Serializable *Callback classes containes non-serializable fields
In-Reply-To: <JIRA.12672954.1485338215000@Atlassian.JIRA>
References: <JIRA.12672954.1485338215000@Atlassian.JIRA>
	<JIRA.12672954.1485338215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672954.1485338215000.15084.1487094840125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7961 to ELY-959:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-959  (was: WFLY-7961)
          Component/s:     (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> Coverity static analysis: Serializable *Callback classes containes non-serializable fields
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-959
>                 URL: https://issues.jboss.org/browse/ELY-959
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity static analysis found, there is couple of *Callback classes, which  are mark as Serializable, and contains non-serializable fields. 
> * CredentialCallback 
> * CredentialUpdateCallback
> * MechanismInformationCallback
> * SSLCallback
> * SecurityIdentityCallback
> * ServerCredentialCallback
> * TrustedAuthoritiesCallback
> Either mark fields as transient or Serializable.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490519&defectInstanceId=2123214&mergedDefectId=1377493



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:55:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-960) Coverity static analysis:
 Suspicious integer expression in BSDUnixDESCryptPasswordImpl (Elytron)
In-Reply-To: <JIRA.12672989.1485349044000@Atlassian.JIRA>
References: <JIRA.12672989.1485349044000@Atlassian.JIRA>
	<JIRA.12672989.1485349044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672989.1485349044000.15089.1487094900309@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7966 to ELY-960:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-960  (was: WFLY-7966)
          Component/s: Passwords
                           (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> Coverity static analysis: Suspicious integer expression in BSDUnixDESCryptPasswordImpl (Elytron)
> ------------------------------------------------------------------------------------------------
>
>                 Key: ELY-960
>                 URL: https://issues.jboss.org/browse/ELY-960
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Passwords
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Seems {{if}} statement will never be {{true}}, because invKeyPerm is of type byte[]. And permitted values for byte are -128...127. 
> {code:java|title=BSDUnixDESCryptPasswordImpl.java}
> outBit = invKeyPerm[inBit];
> if (outBit == 255) {
>     continue;
> }
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553812&defectInstanceId=2138962&mergedDefectId=1377479&fileStart=1&fileEnd=250



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:57:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-961) Coverity: Incorrect definition
 of RawKey as a parent of Serializable classes
In-Reply-To: <JIRA.12672994.1485349635000@Atlassian.JIRA>
References: <JIRA.12672994.1485349635000@Atlassian.JIRA>
	<JIRA.12672994.1485349635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672994.1485349635000.15098.1487095020267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7967 to ELY-961:
-----------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-961  (was: WFLY-7967)
    Component/s:     (was: Security)


> Coverity: Incorrect definition of RawKey as a parent of Serializable classes
> ----------------------------------------------------------------------------
>
>                 Key: ELY-961
>                 URL: https://issues.jboss.org/browse/ELY-961
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> There are some Serializable classes, which extends from RawKey, which is not Serializable.
> *     RawRSAPrivateKey
> *     RawDHPrivateKey
> *     RawPBEKey
> *     RawECPrivateKey
> *     RawDSAPrivateKey
> Either mark RawKey as Serializable as well or if this is not desired, provide no-args constructor in RawKey class, as javadoc describes:
> ??During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream. [1]??
> [1] http://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553919&defectInstanceId=2138989&mergedDefectId=1377488



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:57:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-961) Coverity: Incorrect definition
 of RawKey as a parent of Serializable classes
In-Reply-To: <JIRA.12672994.1485349635000@Atlassian.JIRA>
References: <JIRA.12672994.1485349635000@Atlassian.JIRA>
	<JIRA.12672994.1485349635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672994.1485349635000.15101.1487095020355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-961:
------------------------------
    Affects Version/s: 1.1.0.Beta24


> Coverity: Incorrect definition of RawKey as a parent of Serializable classes
> ----------------------------------------------------------------------------
>
>                 Key: ELY-961
>                 URL: https://issues.jboss.org/browse/ELY-961
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> There are some Serializable classes, which extends from RawKey, which is not Serializable.
> *     RawRSAPrivateKey
> *     RawDHPrivateKey
> *     RawPBEKey
> *     RawECPrivateKey
> *     RawDSAPrivateKey
> Either mark RawKey as Serializable as well or if this is not desired, provide no-args constructor in RawKey class, as javadoc describes:
> ??During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream. [1]??
> [1] http://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553919&defectInstanceId=2138989&mergedDefectId=1377488



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:58:00 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Tue, 14 Feb 2017 12:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7093) Transfer of contextData back
 to the jboss ejb client
In-Reply-To: <JIRA.12649780.1473690854000@Atlassian.JIRA>
References: <JIRA.12649780.1473690854000@Atlassian.JIRA>
	<JIRA.12649780.1473690854000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649780.1473690854000.15107.1487095080481@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolf-Dieter Fink closed WFLY-7093.
----------------------------------
    Resolution: Duplicate Issue


First is WFLY-1805

> Transfer of contextData back to the jboss ejb client
> ----------------------------------------------------
>
>                 Key: WFLY-7093
>                 URL: https://issues.jboss.org/browse/WFLY-7093
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Teresa Miyar
>            Assignee: David Lloyd
>            Priority: Minor
>         Attachments: MethodInvocationMessageHandler.java.diff, MethodInvocationResponseHandler.java.diff
>
>
> The spec says:
> The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation.
> The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 12:59:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 12:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-962) Coverity: Incorrect definition
 of Serializable classes *PrivateKey (Elytron)
In-Reply-To: <JIRA.12672996.1485350193000@Atlassian.JIRA>
References: <JIRA.12672996.1485350193000@Atlassian.JIRA>
	<JIRA.12672996.1485350193000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672996.1485350193000.15110.1487095140162@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7968 to ELY-962:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-962  (was: WFLY-7968)
          Component/s:     (was: Security)
    Affects Version/s: 1.1.0.Beta24
                           (was: 11.0.0.Alpha1)


> Coverity: Incorrect definition of Serializable classes *PrivateKey (Elytron)
> ----------------------------------------------------------------------------
>
>                 Key: ELY-962
>                 URL: https://issues.jboss.org/browse/ELY-962
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> There are couple of classes marked as Serializable, but containing non-serializable fields.
> *     RawECPrivateKey
> *     RawDHPrivateKey
> *     RawDSAPrivateKey
> *     RawRSAMultiPrimePrivateCrtKey
> Mark non-serializable fields transient or Serializable
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553934&defectInstanceId=2138981&mergedDefectId=1377487



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 13:01:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 13:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-963) Coverity static analysis,
 Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
In-Reply-To: <JIRA.12676552.1487061917000@Atlassian.JIRA>
References: <JIRA.12676552.1487061917000@Atlassian.JIRA>
	<JIRA.12676552.1487061917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676552.1487061917000.15119.1487095260266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-8107 to ELY-963:
-----------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-963  (was: WFLY-8107)
    Component/s:     (was: Security)


> Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
> -----------------------------------------------------------------------------------
>
>                 Key: ELY-963
>                 URL: https://issues.jboss.org/browse/ELY-963
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.
> {code:java}
>     private X509Certificate getClientCertificate() throws SaslException {
>         if ((clientCertChain != null) && (clientCertChain.length > 0)) {
>             return clientCertChain[0];
>         } else if (clientCertUrl != null) {
>             try {
>                 return EntityUtil.getCertificateFromUrl(clientCertUrl);
>             } catch (IOException e) {
>                 throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
>             }
>         } else {
>             throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 13:02:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 14 Feb 2017 13:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-963) Coverity static analysis,
 Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
In-Reply-To: <JIRA.12676552.1487061917000@Atlassian.JIRA>
References: <JIRA.12676552.1487061917000@Atlassian.JIRA>
	<JIRA.12676552.1487061917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676552.1487061917000.15122.1487095320137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-963:
------------------------------
    Affects Version/s: 1.1.0.Beta24


> Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
> -----------------------------------------------------------------------------------
>
>                 Key: ELY-963
>                 URL: https://issues.jboss.org/browse/ELY-963
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.
> {code:java}
>     private X509Certificate getClientCertificate() throws SaslException {
>         if ((clientCertChain != null) && (clientCertChain.length > 0)) {
>             return clientCertChain[0];
>         } else if (clientCertUrl != null) {
>             try {
>                 return EntityUtil.getCertificateFromUrl(clientCertUrl);
>             } catch (IOException e) {
>                 throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
>             }
>         } else {
>             throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 13:09:00 2017
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 14 Feb 2017 13:09:00 -0500 (EST)
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: <JIRA.12497139.1374586120000@Atlassian.JIRA>
References: <JIRA.12497139.1374586120000@Atlassian.JIRA>
	<JIRA.12497139.1374586120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.15136.1487095740176@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFLY-1805:
-------------------------------
    Issue Type: Bug  (was: Feature Request)


> 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  Tue Feb 14 13:11:01 2017
From: issues at jboss.org (Wolf-Dieter Fink (JIRA))
Date: Tue, 14 Feb 2017 13:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8114) 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: <JIRA.12676819.1487095859000@Atlassian.JIRA>
References: <JIRA.12676819.1487095859000@Atlassian.JIRA>
	<JIRA.12676819.1487095859801@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676819.1487095859000.15174.1487095861617@Atlassian.JIRA>

Wolf-Dieter Fink created WFLY-8114:
--------------------------------------

             Summary: 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-8114
                 URL: https://issues.jboss.org/browse/WFLY-8114
             Project: WildFly
          Issue Type: Bug
          Components: EJB
            Reporter: Wolf-Dieter Fink
            Assignee: David Lloyd


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  Tue Feb 14 13:27:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 13:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8104) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676520.1487056739000@Atlassian.JIRA>
References: <JIRA.12676520.1487056739000@Atlassian.JIRA>
	<JIRA.12676520.1487056739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676520.1487056739000.15246.1487096820508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8104:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8104
>                 URL: https://issues.jboss.org/browse/WFLY-8104
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Coverity found 2 possible occurences of dereferencing null.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359321&mergedDefectId=1395588
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359320&mergedDefectId=1396462
> {code:java}
>     private char[] resolvePassword() throws Exception {
>         ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
>         CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
>         if (cs != null) {
>             return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
>         } else {
>             throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
>         }
>     }
> {code}
> Both {{getCredential(Class<C> credentialType)}} and {{getPassword(Class<P> type)}} have in javadoc mentioned return value can be null.
> Also in org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder.SimpleDirContextFactory.obtainDirContext(org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode) returned value are explicitely checked on null value.
> Add null check also in {{resolvePassword()}} method



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 13:56:00 2017
From: issues at jboss.org (R Searls (JIRA))
Date: Tue, 14 Feb 2017 13:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8115) Add integration tests for
	jaxrs.
In-Reply-To: <JIRA.12676822.1487098541000@Atlassian.JIRA>
References: <JIRA.12676822.1487098541000@Atlassian.JIRA>
	<JIRA.12676822.1487098541477@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676822.1487098541000.15355.1487098560101@Atlassian.JIRA>

R Searls created WFLY-8115:
------------------------------

             Summary: Add integration tests for jaxrs.
                 Key: WFLY-8115
                 URL: https://issues.jboss.org/browse/WFLY-8115
             Project: WildFly
          Issue Type: Task
          Components: REST
    Affects Versions: 11.0.0.Alpha1
            Reporter: R Searls
            Assignee: R Searls
            Priority: Minor


Add integration tests that preform testing of jaxrs 2.0 spec rules for archive processing.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 13:57:00 2017
From: issues at jboss.org (R Searls (JIRA))
Date: Tue, 14 Feb 2017 13:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8115) Add integration tests for
	jaxrs
In-Reply-To: <JIRA.12676822.1487098541000@Atlassian.JIRA>
References: <JIRA.12676822.1487098541000@Atlassian.JIRA>
	<JIRA.12676822.1487098541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676822.1487098541000.15362.1487098620412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

R Searls updated WFLY-8115:
---------------------------
    Summary: Add integration tests for jaxrs  (was: Add integration tests for jaxrs.)


> Add integration tests for jaxrs
> -------------------------------
>
>                 Key: WFLY-8115
>                 URL: https://issues.jboss.org/browse/WFLY-8115
>             Project: WildFly
>          Issue Type: Task
>          Components: REST
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: R Searls
>            Assignee: R Searls
>            Priority: Minor
>
> Add integration tests that preform testing of jaxrs 2.0 spec rules for archive processing.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 14:00:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 14:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8103) Coverity static analysis,
 Dereference after null check, KeyStoreService (elytron-subsystem)
In-Reply-To: <JIRA.12676517.1487055265000@Atlassian.JIRA>
References: <JIRA.12676517.1487055265000@Atlassian.JIRA>
	<JIRA.12676517.1487055265000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676517.1487055265000.15380.1487098800505@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8103:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) 
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8103
>                 URL: https://issues.jboss.org/browse/WFLY-8103
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>             Fix For: 11.0.0.Alpha1
>
>
> Coverity found 2 occurences of possible null dereference.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359322&mergedDefectId=1395584
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=9564434&defectInstanceId=2359323&mergedDefectId=1395585
> Method {{resolvePassword()}} is dereferencing {{resolvedPath}} field
> {code}
>     private char[] resolvePassword() throws Exception {
>         ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
>         CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
>         if (cs != null) {
>             return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
>         } else {
>             throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
>         }
>     }
> {code}
> And method {{resolvePassword()}} is called 2 times from block, where resolvedPath is checked on null
> {code}
>     try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
>         AtomicLoadKeyStore.LoadKey loadKey = keyStore.revertibleLoad(is, resolvePassword());
>     try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
>         char[] password = resolvePassword();
> {code}
> Add null check into {{resolvePassword()}} method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 14:22:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 14 Feb 2017 14:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8100) Use
 RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
In-Reply-To: <JIRA.12676499.1487025178000@Atlassian.JIRA>
References: <JIRA.12676499.1487025178000@Atlassian.JIRA>
	<JIRA.12676499.1487025178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676499.1487025178000.15493.1487100120203@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8100:
-------------------------------
    Affects Version/s: No Release
                           (was: 10.1.0.Final)


> Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
> --------------------------------------------------------------------------
>
>                 Key: WFLY-8100
>                 URL: https://issues.jboss.org/browse/WFLY-8100
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: No Release
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 14:31:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 14:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8116) Upgrade to Elytron Subsystem
	1.0.0.Beta7
In-Reply-To: <JIRA.12676824.1487100621000@Atlassian.JIRA>
References: <JIRA.12676824.1487100621000@Atlassian.JIRA>
	<JIRA.12676824.1487100621660@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676824.1487100621000.15581.1487100660444@Atlassian.JIRA>

Darran Lofthouse created WFLY-8116:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Beta7
                 Key: WFLY-8116
                 URL: https://issues.jboss.org/browse/WFLY-8116
             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  Tue Feb 14 14:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 14 Feb 2017 14:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8116) Upgrade to Elytron Subsystem
	1.0.0.Beta8
In-Reply-To: <JIRA.12676824.1487100622000@Atlassian.JIRA>
References: <JIRA.12676824.1487100622000@Atlassian.JIRA>
	<JIRA.12676824.1487100622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676824.1487100622000.15635.1487101860389@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8116:
-----------------------------------
    Summary: Upgrade to Elytron Subsystem 1.0.0.Beta8  (was: Upgrade to Elytron Subsystem 1.0.0.Beta7)


> Upgrade to Elytron Subsystem 1.0.0.Beta8
> ----------------------------------------
>
>                 Key: WFLY-8116
>                 URL: https://issues.jboss.org/browse/WFLY-8116
>             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  Tue Feb 14 15:57:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.15929.1487105825087@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.15937.1487105825407@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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 Feb 14 15:57:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.15941.1487105825531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta2, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Tue Feb 14 15:57:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.15948.1487105825807@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.15955.1487105825985@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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 Feb 14 15:57:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.15965.1487105826279@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:06 -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: <JIRA.12666705.1481282688000@Atlassian.JIRA>
References: <JIRA.12666705.1481282688000@Atlassian.JIRA>
	<JIRA.12666705.1481282688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666705.1481282688000.15972.1487105826499@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron
	1.1.0.Final
In-Reply-To: <JIRA.12666683.1481279343000@Atlassian.JIRA>
References: <JIRA.12666683.1481279343000@Atlassian.JIRA>
	<JIRA.12666683.1481279343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666683.1481279343000.15979.1487105826665@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.15988.1487105826968@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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  Tue Feb 14 15:57:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.15995.1487105827227@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.16003.1487105827432@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>         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  Tue Feb 14 15:57:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:07 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.16011.1487105827654@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.16014.1487105827735@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta2
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.16022.1487105827917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1964:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta2
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1962) Deprecate
 ParameterValidator.validateResolvedParameter, try and get rid of uses of it
In-Reply-To: <JIRA.12660247.1478625712000@Atlassian.JIRA>
References: <JIRA.12660247.1478625712000@Atlassian.JIRA>
	<JIRA.12660247.1478625712000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660247.1478625712000.16034.1487105828273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1962:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1962
>                 URL: https://issues.jboss.org/browse/WFCORE-1962
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> The ParameterValidator.validateResolvedParameter method specifies the impl should call ModelNode.resolve() and then validate that. This is a broken contract as ModelNode.resolve() is not the expression resolution mechanism of WildFly.
> This code is only used in a few places. The normal way resolution + validation happens is outside code (e.g. AttributeDefinition) resolves the value and then calls the normal ParameterValidator.validateParameter method.
> So, task here is to look into the few uses of this method in core and full, determine they can be changed to no longer use it, change them, then deprecate this method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.16050.1487105828798@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.16038.1487105828395@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>         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<String, String>, 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  Tue Feb 14 15:57:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.16064.1487105829322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.16043.1487105828569@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.16056.1487105828992@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.16074.1487105829648@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly
 handles duplicate module names
In-Reply-To: <JIRA.12643479.1471302678000@Atlassian.JIRA>
References: <JIRA.12643479.1471302678000@Atlassian.JIRA>
	<JIRA.12643479.1471302678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643479.1471302678000.16069.1487105829478@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1717:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
>                 Key: WFCORE-1717
>                 URL: https://issues.jboss.org/browse/WFCORE-1717
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
>            Reporter: Toby Crawley
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:09 -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: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.16083.1487105829949@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.16091.1487105830111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1489:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 3.0.0.Beta2
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12626950.1463652179000@Atlassian.JIRA>
References: <JIRA.12626950.1463652179000@Atlassian.JIRA>
	<JIRA.12626950.1463652179000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626950.1463652179000.16087.1487105830037@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>         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  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1441) Threads resource classes
 should make it easy for users to declare capabilities
In-Reply-To: <JIRA.12610985.1458236449000@Atlassian.JIRA>
References: <JIRA.12610985.1458236449000@Atlassian.JIRA>
	<JIRA.12610985.1458236449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610985.1458236449000.16094.1487105830182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1441:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Threads resource classes should make it easy for users to declare capabilities
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-1441
>                 URL: https://issues.jboss.org/browse/WFCORE-1441
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking.
> But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities.
> Things probably needed:
> 1) Ability to declare the capability that should be registered when a resource is created.
> 2) Ability to declare the capability that model reference attributes in a resource refer to.
> Perhaps others, but those are the ones that come immediately to mind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.16105.1487105830474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Beta2
>
>         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  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1337) Provide capabilities for
	paths
In-Reply-To: <JIRA.12601540.1453925361000@Atlassian.JIRA>
References: <JIRA.12601540.1453925361000@Atlassian.JIRA>
	<JIRA.12601540.1453925361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601540.1453925361000.16108.1487105830532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1337:
-------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Provide capabilities for paths
> ------------------------------
>
>                 Key: WFCORE-1337
>                 URL: https://issues.jboss.org/browse/WFCORE-1337
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> 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  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.16117.1487105830828@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>         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  Tue Feb 14 15:57:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.16123.1487105830998@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.16127.1487105831191@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.16132.1487105831432@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-972:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.16136.1487105831579@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> "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.Beta2
>
>
> 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  Tue Feb 14 15:57:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.16143.1487105831853@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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.<init>(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  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.16149.1487105832010@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-459:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta2
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57: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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.16153.1487105832119@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -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: <JIRA.12469962.1341563495000@Atlassian.JIRA>
References: <JIRA.12469962.1341563495000@Atlassian.JIRA>
	<JIRA.12469962.1341563495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469962.1341563495000.16158.1487105832303@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-377:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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, management
>             Fix For: 3.0.0.Beta2
>
>
> 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  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.16162.1487105832453@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-266:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta2
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -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: <JIRA.12468578.1339443565000@Atlassian.JIRA>
References: <JIRA.12468578.1339443565000@Atlassian.JIRA>
	<JIRA.12468578.1339443565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468578.1339443565000.16169.1487105832673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-185:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> 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: rhq
>             Fix For: 3.0.0.Beta2
>
>
> 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  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.16172.1487105832760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-107:
------------------------------
    Fix Version/s: 3.0.0.Beta2
                       (was: 3.0.0.Beta1)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta2
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 15:57:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 14 Feb 2017 15:57:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.16178.1487105832939@Atlassian.JIRA>


     [ 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.Beta2
                       (was: 3.0.0.Beta1)


> 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.Beta2
>
>
> 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  Tue Feb 14 15:58:00 2017
From: issues at jboss.org (Joey Wang (JIRA))
Date: Tue, 14 Feb 2017 15:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1548) Access denied when
 deploying to wildfly 10
In-Reply-To: <JIRA.12618242.1462434992000@Atlassian.JIRA>
References: <JIRA.12618242.1462434992000@Atlassian.JIRA>
	<JIRA.12618242.1462434992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618242.1462434992000.16185.1487105880221@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363485#comment-13363485 ] 

Joey Wang commented on WFCORE-1548:
-----------------------------------

[~ctomc], do you know why it is not a problem when deploying via web console? The problem happens when deploy from CLI remotely or Wildfly Maven plugin remotely.

> 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  Tue Feb 14 16:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 16:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-972) Provide a way to correlate
 HTTP management requests
In-Reply-To: <JIRA.12578349.1437117633000@Atlassian.JIRA>
References: <JIRA.12578349.1437117633000@Atlassian.JIRA>
	<JIRA.12578349.1437117633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578349.1437117633000.16206.1487106480121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-972:
------------------------------------
    Fix Version/s: 4.0.0.Alpha1
                       (was: 3.0.0.Beta2)


> Provide a way to correlate HTTP management requests
> ---------------------------------------------------
>
>                 Key: WFCORE-972
>                 URL: https://issues.jboss.org/browse/WFCORE-972
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha1
>
>
> {noformat}
> public class CorrelationHandler implements HttpHandler {
>     private static final HttpString HEADER = new HttpString("X-CORR-ID");
>     private final HttpHandler next;
>     public CorrelationHandler(HttpHandler next) {
>         this.next = next;
>     }
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception {
>         String corr = exchange.getRequestHeaders().getFirst(HEADER);
>         if(corr != null) {
>             exchange.getResponseHeaders().put(HEADER, corr);
>         }
>         next.handleRequest(exchange);
>     }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 16:17:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 16:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1337) Provide capabilities for
	paths
In-Reply-To: <JIRA.12601540.1453925361000@Atlassian.JIRA>
References: <JIRA.12601540.1453925361000@Atlassian.JIRA>
	<JIRA.12601540.1453925361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12601540.1453925361000.16212.1487107020144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1337:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta2)


> Provide capabilities for paths
> ------------------------------
>
>                 Key: WFCORE-1337
>                 URL: https://issues.jboss.org/browse/WFCORE-1337
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> 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  Tue Feb 14 16:38:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 14 Feb 2017 16:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8117) Require Maven 3.3.1+ and
	introduce mvnw
In-Reply-To: <JIRA.12676835.1487108224000@Atlassian.JIRA>
References: <JIRA.12676835.1487108224000@Atlassian.JIRA>
	<JIRA.12676835.1487108224841@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676835.1487108224000.16290.1487108280509@Atlassian.JIRA>

Tomaz Cerar created WFLY-8117:
---------------------------------

             Summary: Require Maven 3.3.1+ and introduce mvnw
                 Key: WFLY-8117
                 URL: https://issues.jboss.org/browse/WFLY-8117
             Project: WildFly
          Issue Type: Task
            Reporter: Tomaz Cerar
            Assignee: Peter Palaga


* Maven 3.3.1+ is required by the Enforcer Plugin
* {{mvnw}} (a.k.a. Maven Wrapper) replaces the legacy {{tools/download-maven.*}} scripts
* {{build.*}} and {{integration-tests.*}} scripts were kept for backwards compatibility.

These changes were discussed on wildfly-dev mailing list.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 16:40:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 14 Feb 2017 16:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8118) Use
 RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
In-Reply-To: <JIRA.12676836.1487108368000@Atlassian.JIRA>
References: <JIRA.12676836.1487108368000@Atlassian.JIRA>
	<JIRA.12676836.1487108368637@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676836.1487108368000.16301.1487108400454@Atlassian.JIRA>

Paul Ferraro created WFLY-8118:
----------------------------------

             Summary: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate
                 Key: WFLY-8118
                 URL: https://issues.jboss.org/browse/WFLY-8118
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: No Release
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 16:41:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 14 Feb 2017 16:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8100) Use
 RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where
 appropriate
In-Reply-To: <JIRA.12676499.1487025178000@Atlassian.JIRA>
References: <JIRA.12676499.1487025178000@Atlassian.JIRA>
	<JIRA.12676499.1487025178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676499.1487025178000.16338.1487108460547@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-8100:
-------------------------------
    Summary: Use RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where appropriate  (was: Use RuntimeCapability.setAllowMultipleRegistrations(...) where appropriate)


> Use RuntimeCapability.Builder.setAllowMultipleRegistrations(...) where appropriate
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-8100
>                 URL: https://issues.jboss.org/browse/WFLY-8100
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: No Release
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 17:25:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 17:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase doesn't
 account for recycling of PIDs
In-Reply-To: <JIRA.12676838.1487111061000@Atlassian.JIRA>
References: <JIRA.12676838.1487111061000@Atlassian.JIRA>
	<JIRA.12676838.1487111061299@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676838.1487111061000.16480.1487111100063@Atlassian.JIRA>

Brian Stansberry created WFCORE-2298:
----------------------------------------

             Summary: RespawnHttpTestCase doesn't account for recycling of PIDs
                 Key: WFCORE-2298
                 URL: https://issues.jboss.org/browse/WFCORE-2298
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Test Suite
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-process-id-pid-numbers/31257979#31257979 and links therein.)

RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted.

For example:

https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&buildTypeId=WildFlyCore_PullRequestWindows



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 17:29:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 14 Feb 2017 17:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8119) NPE in mod_cluster stopping
In-Reply-To: <JIRA.12676839.1487111272000@Atlassian.JIRA>
References: <JIRA.12676839.1487111272000@Atlassian.JIRA>
	<JIRA.12676839.1487111272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676839.1487111272000.16514.1487111340312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-8841 to WFLY-8119:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8119  (was: JBEAP-8841)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: mod_cluster
                           (was: mod_cluster)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR10)


> NPE in mod_cluster stopping
> ---------------------------
>
>                 Key: WFLY-8119
>                 URL: https://issues.jboss.org/browse/WFLY-8119
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Don't know what causing it or how to reproduce it.
> It started to show with EAP 7.1.0.DR10.
> At first glance it shows quite randomly without any significant effect on server
> {noformat}
> 2017-01-11 08:29:19,989 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.8.Final-redhat-1 stopping
> 2017-01-11 08:29:20,108 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) null: java.lang.NullPointerException
> 	at org.jboss.modcluster.ModClusterService.connectionEstablished(ModClusterService.java:305)
> 	at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:392)
> 	at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365)
> 	at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454)
> 	at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 	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}
> http://paste.fedoraproject.org/530763/30767148/



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 17:42:02 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 17:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and
 RespawnTestCase don't account for recycling of PIDs
In-Reply-To: <JIRA.12676838.1487111061000@Atlassian.JIRA>
References: <JIRA.12676838.1487111061000@Atlassian.JIRA>
	<JIRA.12676838.1487111061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676838.1487111061000.16689.1487112122059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2298:
-------------------------------------
    Summary: RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs  (was: RespawnHttpTestCase doesn't account for recycling of PIDs)


> RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-2298
>                 URL: https://issues.jboss.org/browse/WFCORE-2298
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-process-id-pid-numbers/31257979#31257979 and links therein.)
> RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted.
> For example:
> https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&buildTypeId=WildFlyCore_PullRequestWindows



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 17:42:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 17:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and
 RespawnTestCase don't account for recycling of PIDs
In-Reply-To: <JIRA.12676838.1487111061000@Atlassian.JIRA>
References: <JIRA.12676838.1487111061000@Atlassian.JIRA>
	<JIRA.12676838.1487111061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676838.1487111061000.16762.1487112124347@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363521#comment-13363521 ] 

Brian Stansberry commented on WFCORE-2298:
------------------------------------------

This probably can't be made perfect (at least not with effort reasonable for the problem) but

1) RunningProcess.equals/hashCode can account for both the PID and the process "type" string.
2) Use that for checking if a process should be ignored, instead of just the PID, so if server-one reloads to the PID used before by server-two, it's not counted as not having reloaded.
3) Check more frequently, with no initial delay
4) Once an excluded process isn't seen, stop excluding it, so if it resurrects its not treated as the old process.

Also, RespawnTestCase and RespawnHttpTestCase should share the utility code here instead of duplicating it.

> RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-2298
>                 URL: https://issues.jboss.org/browse/WFCORE-2298
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-process-id-pid-numbers/31257979#31257979 and links therein.)
> RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted.
> For example:
> https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&buildTypeId=WildFlyCore_PullRequestWindows



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 17:43:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 14 Feb 2017 17:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2298) RespawnHttpTestCase and
 RespawnTestCase don't account for recycling of PIDs
In-Reply-To: <JIRA.12676838.1487111061000@Atlassian.JIRA>
References: <JIRA.12676838.1487111061000@Atlassian.JIRA>
	<JIRA.12676838.1487111061000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676838.1487111061000.16799.1487112181917@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363522#comment-13363522 ] 

Brian Stansberry commented on WFCORE-2298:
------------------------------------------

If this isn't resolved soon, anyone should feel free to take it.

> RespawnHttpTestCase and RespawnTestCase don't account for recycling of PIDs
> ---------------------------------------------------------------------------
>
>                 Key: WFCORE-2298
>                 URL: https://issues.jboss.org/browse/WFCORE-2298
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> On Windows, apparently PIDs can be recycled in such a way that they can reappear shortly after the first process with a PID is terminated. (See http://stackoverflow.com/questions/26301382/does-windows-7-recycle-process-id-pid-numbers/31257979#31257979 and links therein.)
> RespawnHttpTestCase is assuming that this won't happen, since when checking for reload completion it ignores any PID that belonged to one of the servers that's expected to be restarted. I'm seeing intermittent failures that seem to be due to this expectation being incorrect, as the logging for the failed tests clearly shows that the servers are restarted.
> For example:
> https://ci.wildfly.org/viewLog.html?buildId=45601&tab=buildResultsDiv&buildTypeId=WildFlyCore_PullRequestWindows



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 22:17:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 14 Feb 2017 22:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-8) Migrate Narayana integration
 module from existent POC repo
In-Reply-To: <JIRA.12676510.1487046001000@Atlassian.JIRA>
References: <JIRA.12676510.1487046001000@Atlassian.JIRA>
	<JIRA.12676510.1487046001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676510.1487046001000.20855.1487128620159@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-8.
----------------------------
    Resolution: Done


> Migrate Narayana integration module from existent POC repo
> ----------------------------------------------------------
>
>                 Key: AG-8
>                 URL: https://issues.jboss.org/browse/AG-8
>             Project: Agroal
>          Issue Type: Task
>          Components: narayana
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 14 22:20:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 14 Feb 2017 22:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-9) Create initial test suite
In-Reply-To: <JIRA.12676854.1487128783000@Atlassian.JIRA>
References: <JIRA.12676854.1487128783000@Atlassian.JIRA>
	<JIRA.12676854.1487128783775@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676854.1487128783000.20858.1487128800109@Atlassian.JIRA>

Luis Barreiro created AG-9:
------------------------------

             Summary: Create initial test suite
                 Key: AG-9
                 URL: https://issues.jboss.org/browse/AG-9
             Project: Agroal
          Issue Type: Task
          Components: test
    Affects Versions: 0.0
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
             Fix For: 0.1






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 00:28:00 2017
From: issues at jboss.org (Lin Gao (JIRA))
Date: Wed, 15 Feb 2017 00:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8120) Upgrade picketlink 2.5.5.SP5
	to 2.5.5.SP6
In-Reply-To: <JIRA.12676862.1487136460000@Atlassian.JIRA>
References: <JIRA.12676862.1487136460000@Atlassian.JIRA>
	<JIRA.12676862.1487136460009@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676862.1487136460000.20958.1487136480132@Atlassian.JIRA>

Lin Gao created WFLY-8120:
-----------------------------

             Summary: Upgrade picketlink 2.5.5.SP5 to 2.5.5.SP6
                 Key: WFLY-8120
                 URL: https://issues.jboss.org/browse/WFLY-8120
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Lin Gao
            Assignee: Kabir Khan






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 02:23:00 2017
From: issues at jboss.org (Teresa Miyar (JIRA))
Date: Wed, 15 Feb 2017 02:23:00 -0500 (EST)
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: <JIRA.12497139.1374586120000@Atlassian.JIRA>
References: <JIRA.12497139.1374586120000@Atlassian.JIRA>
	<JIRA.12497139.1374586120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.21100.1487143380401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Teresa Miyar updated WFLY-1805:
-------------------------------
    SourceForge Reference: https://access.redhat.com/support/cases/01682712


> 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  Wed Feb 15 04:07:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 15 Feb 2017 04:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8121)
 WeldDeployment.loadBeanDeploymentArchive() may create multiple bean
 deployment archives with the same id
In-Reply-To: <JIRA.12676884.1487149581000@Atlassian.JIRA>
References: <JIRA.12676884.1487149581000@Atlassian.JIRA>
	<JIRA.12676884.1487149581422@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676884.1487149581000.21633.1487149620616@Atlassian.JIRA>

Martin Kouba created WFLY-8121:
----------------------------------

             Summary: WeldDeployment.loadBeanDeploymentArchive() may create multiple bean deployment archives with the same id
                 Key: WFLY-8121
                 URL: https://issues.jboss.org/browse/WFLY-8121
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 11.0.0.Alpha1


This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract.

The use case is described in https://issues.jboss.org/browse/WELD-2165?focusedCommentId=13286271&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13286271.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 04:36:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 15 Feb 2017 04:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071266000@Atlassian.JIRA>
References: <JIRA.12676576.1487071266000@Atlassian.JIRA>
	<JIRA.12676576.1487071266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071266000.21811.1487151360087@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-8109:
--------------------------------
    Description: 
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.

  was:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase timeout in LegacyConfigTest
* increase timeout in DomainHostExcludesTest
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.



> Improve timeouts in AS TS
> -------------------------
>
>                 Key: WFLY-8109
>                 URL: https://issues.jboss.org/browse/WFLY-8109
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb 15 04:46:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 15 Feb 2017 04:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071266000@Atlassian.JIRA>
References: <JIRA.12676576.1487071266000@Atlassian.JIRA>
	<JIRA.12676576.1487071266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071266000.21861.1487151960143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-8109:
--------------------------------
    Description: 
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.

  was:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.



> Improve timeouts in AS TS
> -------------------------
>
>                 Key: WFLY-8109
>                 URL: https://issues.jboss.org/browse/WFLY-8109
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb 15 04:53:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 15 Feb 2017 04:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-964) Coverity static analysis,
 Resource leak on an exceptional path, FileAuditEndpoint (elytron)
In-Reply-To: <JIRA.12676896.1487152339000@Atlassian.JIRA>
References: <JIRA.12676896.1487152339000@Atlassian.JIRA>
	<JIRA.12676896.1487152339528@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676896.1487152339000.21905.1487152380677@Atlassian.JIRA>

Martin Choma created ELY-964:
--------------------------------

             Summary: Coverity static analysis, Resource leak on an exceptional path, FileAuditEndpoint (elytron)
                 Key: ELY-964
                 URL: https://issues.jboss.org/browse/ELY-964
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Coverity static analysis found possible occurence of resource leak.

https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9690272&defectInstanceId=2391428&mergedDefectId=1402977

In constructor when {{fos.getFD()}} will throw exception {{FileOutputStream fos}} won't be closed.

{code:java|title=FileAuditEndpoint.java}
    FileAuditEndpoint(Builder builder) throws IOException {
        this.dateFormatSupplier = builder.dateFormatSupplier;
        this.syncOnAccept = builder.syncOnAccept;

        FileOutputStream fos = new FileOutputStream(builder.location.toFile(), true);
        this.fileDescriptor = fos.getFD();
        this.outputStream = new BufferedOutputStream(fos);
    }
{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 04:55:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 04:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7164) Complex type
 http-authentication-factory in Elytron subsystem
In-Reply-To: <JIRA.12651162.1474458178000@Atlassian.JIRA>
References: <JIRA.12651162.1474458178000@Atlassian.JIRA>
	<JIRA.12651162.1474458178000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651162.1474458178000.21952.1487152501444@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-7164.
----------------------------
    Resolution: Rejected


As discussed in JBEAP-6100, change of complex attributes to subresources would not have supposed positive consequences - closing.

> Complex type http-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-7164
>                 URL: https://issues.jboss.org/browse/WFLY-7164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in http-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex attributes in add operation and resource description:
> mechanism-configurations
> mechanism-realm-configurations.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 04:56:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 04:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7168) Complex type
 sasl-authentication-factory in Elytron subsystem
In-Reply-To: <JIRA.12651181.1474461452000@Atlassian.JIRA>
References: <JIRA.12651181.1474461452000@Atlassian.JIRA>
	<JIRA.12651181.1474461452000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651181.1474461452000.21977.1487152560790@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-7168.
----------------------------
    Resolution: Rejected


As discussed in JBEAP-6100, change of complex attributes to subresources would not have supposed positive consequences - closing.

> Complex type sasl-authentication-factory in Elytron subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-7168
>                 URL: https://issues.jboss.org/browse/WFLY-7168
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in sasl-authentication-factory resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> Complex attributes in add operation and resource description:
> mechanism-configurations
> mechanism-realm-configurations



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:08:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 15 Feb 2017 05:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8122) Backport Latest Elytron and
 Invocation Integration Changes
In-Reply-To: <JIRA.12676899.1487153249000@Atlassian.JIRA>
References: <JIRA.12676899.1487153249000@Atlassian.JIRA>
	<JIRA.12676899.1487153249569@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676899.1487153249000.22071.1487153280615@Atlassian.JIRA>

Darran Lofthouse created WFLY-8122:
--------------------------------------

             Summary: Backport Latest Elytron and Invocation Integration Changes
                 Key: WFLY-8122
                 URL: https://issues.jboss.org/browse/WFLY-8122
             Project: WildFly
          Issue Type: Task
            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 Feb 15 05:14:00 2017
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Wed, 15 Feb 2017 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8053) Warn user when configuration
 change might make server inoperable
In-Reply-To: <JIRA.12675415.1486531913000@Atlassian.JIRA>
References: <JIRA.12675415.1486531913000@Atlassian.JIRA>
	<JIRA.12675415.1486531913000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675415.1486531913000.22124.1487153640309@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski reassigned WFLY-8053:
----------------------------------------

    Assignee: Bartosz Baranowski  (was: Jason Greene)


> Warn user when configuration change might make server inoperable
> ----------------------------------------------------------------
>
>                 Key: WFLY-8053
>                 URL: https://issues.jboss.org/browse/WFLY-8053
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:15:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 05:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8094) Coverity static analysis,
 Resource leak, LdapsecurityRealm (Elytron)
In-Reply-To: <JIRA.12676243.1486989526000@Atlassian.JIRA>
References: <JIRA.12676243.1486989526000@Atlassian.JIRA>
	<JIRA.12676243.1486989526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676243.1486989526000.22139.1487153700315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-8094:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Coverity static analysis, Resource leak, LdapsecurityRealm (Elytron)
> --------------------------------------------------------------------
>
>                 Key: WFLY-8094
>                 URL: https://issues.jboss.org/browse/WFLY-8094
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> Coverity static analysis found 8 occurence of Closeable object LdapIdentity not closing properly. 
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359307&mergedDefectId=1400389
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359304&mergedDefectId=1400388
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359309&mergedDefectId=1400387
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359306&mergedDefectId=1400386
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359311&mergedDefectId=1400385
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359312&mergedDefectId=1400384
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359313&mergedDefectId=1400383
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359303&mergedDefectId=1400382
> {{LdapIdentity}} in {{close()}} method just close provided dirContext. {{LdapIdentity}} does not create dirContext by itself. So it looks to me it is no necessary to implement Closeable in {{LdapIdentity}}, as code where dirContext was created should be responsible for closing it (and according to coverity it is closed properly everywhere).
> {code:java|title=LdapSecurityRealm.java}
>         private class LdapIdentity implements Closeable {
>             private final String name;
>             private final DirContext dirContext;
>             private final String distinguishedName;
>             private final SearchResult entry;
>             LdapIdentity(String name, DirContext dirContext, String distinguishedName, SearchResult entry) {
>                 this.name = name;
>                 this.dirContext = dirContext;
>                 this.distinguishedName = distinguishedName;
>                 this.entry = entry;
>             }
>             String getName() {
>                 return this.name;
>             }
>             DirContext getDirContext() {
>                 return this.dirContext;
>             }
>             String getDistinguishedName() {
>                 return this.distinguishedName;
>             }
>             SearchResult getEntry() {
>                 return this.entry;
>             }
>             @Override
>             public void close() throws IOException {
>                 try {
>                     dirContext.close();
>                 } catch (NamingException e) {
>                     log.debug("LdapSecurityRealm failed to close DirContext", e);
>                 }
>             }
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:16:00 2017
From: issues at jboss.org (Anton Giertli (JIRA))
Date: Wed, 15 Feb 2017 05:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1442) ServiceRegistry references
 non existent classes
In-Reply-To: <JIRA.12676900.1487153704000@Atlassian.JIRA>
References: <JIRA.12676900.1487153704000@Atlassian.JIRA>
	<JIRA.12676900.1487153704040@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676900.1487153704000.22143.1487153760224@Atlassian.JIRA>

Anton Giertli created DROOLS-1442:
-------------------------------------

             Summary: ServiceRegistry references non existent classes
                 Key: DROOLS-1442
                 URL: https://issues.jboss.org/browse/DROOLS-1442
             Project: Drools
          Issue Type: Bug
            Reporter: Anton Giertli
            Assignee: Mario Fusco


This code

{code:java}
        SystemEventListener listener =  SystemEventListenerFactory.getSystemEventListener();
{code}

Fails with:

Caused by: java.lang.ClassNotFoundException: org.drools.core.impl.SystemEventListenerServiceImpl

Because ServiceRegistryImpl 
https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/master/kie-internal/src/main/java/org/kie/internal/utils/ServiceRegistryImpl.java#L189
references class SystemEventListenerServiceImpl which does not exist anymore in drools-core.

The interface SystemEventListenerService still exists in kie-internal but there is no implementation whatsoever in drools.

First impression is that both SystemEventListenerService + SystemEventListenerServiceImpl are "dead" code and should probably be removed.






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:21:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 05:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-965) Coverity static analysis,
 Resource leak, LdapsecurityRealm (Elytron)
In-Reply-To: <JIRA.12676243.1486989526000@Atlassian.JIRA>
References: <JIRA.12676243.1486989526000@Atlassian.JIRA>
	<JIRA.12676243.1486989526000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676243.1486989526000.22155.1487154060314@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina moved WFLY-8094 to ELY-965:
--------------------------------------

        Project: WildFly Elytron  (was: WildFly)
            Key: ELY-965  (was: WFLY-8094)
    Component/s: Realms
                     (was: Security)


> Coverity static analysis, Resource leak, LdapsecurityRealm (Elytron)
> --------------------------------------------------------------------
>
>                 Key: ELY-965
>                 URL: https://issues.jboss.org/browse/ELY-965
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> Coverity static analysis found 8 occurence of Closeable object LdapIdentity not closing properly. 
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359307&mergedDefectId=1400389
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359304&mergedDefectId=1400388
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359309&mergedDefectId=1400387
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359306&mergedDefectId=1400386
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359311&mergedDefectId=1400385
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359312&mergedDefectId=1400384
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359313&mergedDefectId=1400383
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564393&defectInstanceId=2359303&mergedDefectId=1400382
> {{LdapIdentity}} in {{close()}} method just close provided dirContext. {{LdapIdentity}} does not create dirContext by itself. So it looks to me it is no necessary to implement Closeable in {{LdapIdentity}}, as code where dirContext was created should be responsible for closing it (and according to coverity it is closed properly everywhere).
> {code:java|title=LdapSecurityRealm.java}
>         private class LdapIdentity implements Closeable {
>             private final String name;
>             private final DirContext dirContext;
>             private final String distinguishedName;
>             private final SearchResult entry;
>             LdapIdentity(String name, DirContext dirContext, String distinguishedName, SearchResult entry) {
>                 this.name = name;
>                 this.dirContext = dirContext;
>                 this.distinguishedName = distinguishedName;
>                 this.entry = entry;
>             }
>             String getName() {
>                 return this.name;
>             }
>             DirContext getDirContext() {
>                 return this.dirContext;
>             }
>             String getDistinguishedName() {
>                 return this.distinguishedName;
>             }
>             SearchResult getEntry() {
>                 return this.entry;
>             }
>             @Override
>             public void close() throws IOException {
>                 try {
>                     dirContext.close();
>                 } catch (NamingException e) {
>                     log.debug("LdapSecurityRealm failed to close DirContext", e);
>                 }
>             }
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:21:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 15 Feb 2017 05:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2299) Backport Latest Elytron and
 Invocation Integration Changes
In-Reply-To: <JIRA.12676903.1487154037000@Atlassian.JIRA>
References: <JIRA.12676903.1487154037000@Atlassian.JIRA>
	<JIRA.12676903.1487154037423@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676903.1487154037000.22160.1487154060488@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2299:
----------------------------------------

             Summary: Backport Latest Elytron and Invocation Integration Changes
                 Key: WFCORE-2299
                 URL: https://issues.jboss.org/browse/WFCORE-2299
             Project: WildFly Core
          Issue Type: Task
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta2






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 05:46:00 2017
From: issues at jboss.org (Ramesh khot (JIRA))
Date: Wed, 15 Feb 2017 05:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-172) Unable to find unambiguous
 method: class java.lang.String.replace(java.lang.String, java.lang.String)
In-Reply-To: <JIRA.12676912.1487155538000@Atlassian.JIRA>
References: <JIRA.12676912.1487155538000@Atlassian.JIRA>
	<JIRA.12676912.1487155538325@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676912.1487155538000.22296.1487155560119@Atlassian.JIRA>

Ramesh khot created JBEE-172:
--------------------------------

             Summary: Unable to find unambiguous method: class java.lang.String.replace(java.lang.String, java.lang.String)
                 Key: JBEE-172
                 URL: https://issues.jboss.org/browse/JBEE-172
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-el-api
    Affects Versions: jboss-el-api_3.0_spec-1.0.7.Final
         Environment: Wildfly 10, Jdk 8

            Reporter: Ramesh khot
            Assignee: Scott Marlow


I am using String.replace('-',' ') function inside jstl/core forEach tag but getting 
Unable to find unambiguous method: class java.lang.String.replace(java.lang.String, java.lang.String)
	at com.sun.faces.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:358)
	at com.sun.faces.facelets.tag.TagAttributeImpl.getValue(TagAttributeImpl.java:322)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.assignUniqueId(ComponentTagHandlerDelegateImpl.java:434)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 07:22:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Feb 2017 07:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8123) Upgrade Artemis
	1.5.3.jbossorg-002
In-Reply-To: <JIRA.12676953.1487161254000@Atlassian.JIRA>
References: <JIRA.12676953.1487161254000@Atlassian.JIRA>
	<JIRA.12676953.1487161254000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676953.1487161254000.23213.1487161320313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8854 to WFLY-8123:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8123  (was: JBEAP-8854)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: ActiveMQ)
                     (was: JMS)


> Upgrade Artemis 1.5.3.jbossorg-002
> ----------------------------------
>
>                 Key: WFLY-8123
>                 URL: https://issues.jboss.org/browse/WFLY-8123
>             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  Wed Feb 15 07:33:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 15 Feb 2017 07:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1441) Nested accumulate makes DRL
 twice as slow in statefull session
In-Reply-To: <JIRA.12676769.1487091369000@Atlassian.JIRA>
References: <JIRA.12676769.1487091369000@Atlassian.JIRA>
	<JIRA.12676769.1487091369000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676769.1487091369000.23264.1487161980152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1441:
-------------------------------------
    Description: 
To reproduce: comment out to replace the 2 rules in this DRL:
  https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-examples/src/main/resources/org/optaplanner/examples/tennis/solver/tennisScoreRules.drl
and run TennisApp

In the sampler profiling, see attachement 350, the original way does setObject() 60% of the time and determineIdentityHashcode 20%, but in the new one way it's vica versa.
so the number of setObjects() calls is probably the same, it's just the determineIdentityHashCode() that blow up.

  was:
To reproduce: comment out to replace the 2 rules in this DRL:
  https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-examples/src/main/resources/org/optaplanner/examples/tennis/solver/tennisScoreRules.drl
and run TennisApp



> Nested accumulate makes DRL twice as slow in statefull session
> --------------------------------------------------------------
>
>                 Key: DROOLS-1441
>                 URL: https://issues.jboss.org/browse/DROOLS-1441
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>         Attachments: Selection_350.png
>
>
> To reproduce: comment out to replace the 2 rules in this DRL:
>   https://github.com/droolsjbpm/optaplanner/blob/master/optaplanner-examples/src/main/resources/org/optaplanner/examples/tennis/solver/tennisScoreRules.drl
> and run TennisApp
> In the sampler profiling, see attachement 350, the original way does setObject() 60% of the time and determineIdentityHashcode 20%, but in the new one way it's vica versa.
> so the number of setObjects() calls is probably the same, it's just the determineIdentityHashCode() that blow up.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 07:36:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1890) wildfly-10.0.0.Final
	deployment crash
In-Reply-To: <JIRA.12613656.1459977826000@Atlassian.JIRA>
References: <JIRA.12613656.1459977826000@Atlassian.JIRA>
	<JIRA.12613656.1459977826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613656.1459977826000.23281.1487162160587@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363833#comment-13363833 ] 

RH Bugzilla Integration commented on WFCORE-1890:
-------------------------------------------------

Miroslav Sochurek <msochure at redhat.com> changed the Status of [bug 1408222|https://bugzilla.redhat.com/show_bug.cgi?id=1408222] from POST to CLOSED

> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
>                 Key: WFCORE-1890
>                 URL: https://issues.jboss.org/browse/WFCORE-1890
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Deployment Scanner
>    Affects Versions: 2.2.0.Final
>            Reporter: Jason Morgan
>            Assignee: ehsavoie Hugonnet
>             Fix For: 3.0.0.Alpha23
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 07:41:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 15 Feb 2017 07:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-964) Coverity static analysis,
 Resource leak on an exceptional path, FileAuditEndpoint (elytron)
In-Reply-To: <JIRA.12676896.1487152340000@Atlassian.JIRA>
References: <JIRA.12676896.1487152340000@Atlassian.JIRA>
	<JIRA.12676896.1487152340000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676896.1487152340000.23315.1487162460465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-964:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Coverity static analysis, Resource leak on an exceptional path, FileAuditEndpoint (elytron)
> -------------------------------------------------------------------------------------------
>
>                 Key: ELY-964
>                 URL: https://issues.jboss.org/browse/ELY-964
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> Coverity static analysis found possible occurence of resource leak.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9690272&defectInstanceId=2391428&mergedDefectId=1402977
> In constructor when {{fos.getFD()}} will throw exception {{FileOutputStream fos}} won't be closed.
> {code:java|title=FileAuditEndpoint.java}
>     FileAuditEndpoint(Builder builder) throws IOException {
>         this.dateFormatSupplier = builder.dateFormatSupplier;
>         this.syncOnAccept = builder.syncOnAccept;
>         FileOutputStream fos = new FileOutputStream(builder.location.toFile(), true);
>         this.fileDescriptor = fos.getFD();
>         this.outputStream = new BufferedOutputStream(fos);
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 07:47:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 15 Feb 2017 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8124) Unify arquillian
	defaultProtocol in TS
In-Reply-To: <JIRA.12676957.1487162780000@Atlassian.JIRA>
References: <JIRA.12676957.1487162780000@Atlassian.JIRA>
	<JIRA.12676957.1487162780129@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676957.1487162780000.23394.1487162820454@Atlassian.JIRA>

Marek Kopeck? created WFLY-8124:
-----------------------------------

             Summary: Unify arquillian defaultProtocol in TS
                 Key: WFLY-8124
                 URL: https://issues.jboss.org/browse/WFLY-8124
             Project: WildFly
          Issue Type: Enhancement
          Components: Test Suite
            Reporter: Marek Kopeck?
            Assignee: Marek Kopeck?


Unify arquillian defaultProtocol in TS

xts a rts module use servlet protocol. Jmx protocol is standard protocol:
{noformat}
[mkopecky at dhcp-10-40-5-170 base] (7.x)$ git grep defaultProtocol | grep -i servlet
testsuite/integration/rts/src/test/config/arq/arquillian.xml:    <defaultProtocol type="Servlet 3.0" />
testsuite/integration/xts/src/test/config/arq/arquillian.xml:    <defaultProtocol type="Servlet 3.0" />
[mkopecky at dhcp-10-40-5-170 base] (7.x)$ git grep defaultProtocol | grep -iv servlet | wc -l
13
[mkopecky at dhcp-10-40-5-170 base] (7.x)$
{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb 15 07:58:02 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 15 Feb 2017 07:58:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8125) Programatically set Elytron
 AuthenticationContext does not work in application server modules
In-Reply-To: <JIRA.12676959.1487163464000@Atlassian.JIRA>
References: <JIRA.12676959.1487163464000@Atlassian.JIRA>
	<JIRA.12676959.1487163464325@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676959.1487163464000.23493.1487163482117@Atlassian.JIRA>

Ondrej Lukas created WFLY-8125:
----------------------------------

             Summary: 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: Darran Lofthouse
            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  Wed Feb 15 07:58:02 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 15 Feb 2017 07:58:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8125) Programatically set Elytron
 AuthenticationContext does not work in application server modules
In-Reply-To: <JIRA.12676959.1487163464000@Atlassian.JIRA>
References: <JIRA.12676959.1487163464000@Atlassian.JIRA>
	<JIRA.12676959.1487163464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676959.1487163464000.23502.1487163482429@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8125:
-------------------------------
    Attachment: module-without-wildfly-config-xml.jar
                module-without-wildfly-config-xml-dep.war


> 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: Darran Lofthouse
>            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  Wed Feb 15 08:13:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 15 Feb 2017 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8126) Default HTTP/2 (=> no openssl
 provider used) doesn't work with curl
In-Reply-To: <JIRA.12676965.1487164378000@Atlassian.JIRA>
References: <JIRA.12676965.1487164378000@Atlassian.JIRA>
	<JIRA.12676965.1487164378474@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676965.1487164378000.23679.1487164380446@Atlassian.JIRA>

Romain Pelisse created WFLY-8126:
------------------------------------

             Summary: Default HTTP/2 (=> no openssl provider used) doesn't work with curl	
                 Key: WFLY-8126
                 URL: https://issues.jboss.org/browse/WFLY-8126
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 10.1.0.Final
            Reporter: Romain Pelisse
            Assignee: Romain Pelisse
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 08:14:00 2017
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Wed, 15 Feb 2017 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8126) Default HTTP/2 (=> no openssl
 provider used) doesn't work with curl
In-Reply-To: <JIRA.12676965.1487164378000@Atlassian.JIRA>
References: <JIRA.12676965.1487164378000@Atlassian.JIRA>
	<JIRA.12676965.1487164378000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676965.1487164378000.23693.1487164440791@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363873#comment-13363873 ] 

Romain Pelisse commented on WFLY-8126:
--------------------------------------

Adding link to upstream issue to JBEAP-8597

> Default HTTP/2 (=> no openssl provider used) doesn't work with curl	
> --------------------------------------------------------------------
>
>                 Key: WFLY-8126
>                 URL: https://issues.jboss.org/browse/WFLY-8126
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>            Priority: Minor
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:02:01 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 15 Feb 2017 09:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8127) Upgrade Narayana to
	5.5.2.Final
In-Reply-To: <JIRA.12676982.1487167300000@Atlassian.JIRA>
References: <JIRA.12676982.1487167300000@Atlassian.JIRA>
	<JIRA.12676982.1487167300895@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676982.1487167300000.24206.1487167321557@Atlassian.JIRA>

Tom Jenkinson created WFLY-8127:
-----------------------------------

             Summary: Upgrade Narayana to 5.5.2.Final
                 Key: WFLY-8127
                 URL: https://issues.jboss.org/browse/WFLY-8127
             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  Wed Feb 15 09:04:01 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 15 Feb 2017 09:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8128) recovery-credential under
 xa-data-source is missing support for credential store references
In-Reply-To: <JIRA.12676983.1487167365000@Atlassian.JIRA>
References: <JIRA.12676983.1487167365000@Atlassian.JIRA>
	<JIRA.12676983.1487167365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676983.1487167365000.24266.1487167441090@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-8859 to WFLY-8128:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8128  (was: JBEAP-8859)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                       Security
                           (was: JCA)
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR11)


> recovery-credential under xa-data-source is missing support for credential store references
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8128
>                 URL: https://issues.jboss.org/browse/WFLY-8128
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, Security
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Blocker
>              Labels: credential-store, jca
>
> {{recovery-credential}} is missing support for {{credential-reference}}
> {code:xml}
> <xa-datasource jndi-name="java:jboss/xa-datasources/test" pool-name="test">
>     <xa-datasource-property name="test">
>         aa
>     </xa-datasource-property>
>     <xa-datasource-property name="test2">
>         aa
>     </xa-datasource-property>
>     <driver>h2</driver>
>     <security>
>         <user-name>sa</user-name>
>         <credential-reference clear-text="password" />
>     </security>
>     <recovery>
>         <recover-credential>
>             <user-name>user</user-name>
>             <password>pass</password>
>         </recover-credential>
>     </recovery>
> </xa-datasource>
> {code}
> {noformat}
> [standalone at embedded /] /subsystem=datasources/xa-data-source=test:write-attribute(name=recovery-username, value=user
> [standalone at embedded /] /subsystem=datasources/xa-data-source=test:write-attribute(name=recovery-password, value=pass
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:06:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 15 Feb 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8127) Upgrade Narayana to
	5.5.2.Final
In-Reply-To: <JIRA.12676982.1487167301000@Atlassian.JIRA>
References: <JIRA.12676982.1487167301000@Atlassian.JIRA>
	<JIRA.12676982.1487167301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676982.1487167301000.24300.1487167560444@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-8127:
--------------------------------
    Description: Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487


> Upgrade Narayana to 5.5.2.Final
> -------------------------------
>
>                 Key: WFLY-8127
>                 URL: https://issues.jboss.org/browse/WFLY-8127
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:09:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 15 Feb 2017 09:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8127) Upgrade Narayana to
	5.5.2.Final
In-Reply-To: <JIRA.12676982.1487167301000@Atlassian.JIRA>
References: <JIRA.12676982.1487167301000@Atlassian.JIRA>
	<JIRA.12676982.1487167301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676982.1487167301000.24334.1487167740930@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-8127:
--------------------------------
    Description: 
Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487
https://github.com/jbosstm/narayana/commits/5.5.2.Final

  was:Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487



> Upgrade Narayana to 5.5.2.Final
> -------------------------------
>
>                 Key: WFLY-8127
>                 URL: https://issues.jboss.org/browse/WFLY-8127
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487
> https://github.com/jbosstm/narayana/commits/5.5.2.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:09:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 09:09:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7158) Working with multiple keys in
	key store
In-Reply-To: <JIRA.12651106.1474433758000@Atlassian.JIRA>
References: <JIRA.12651106.1474433758000@Atlassian.JIRA>
	<JIRA.12651106.1474433758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651106.1474433758000.24343.1487167741239@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363934#comment-13363934 ] 

Jan Kalina commented on WFLY-7158:
----------------------------------

Current status: key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
Required status: key-manager use credential-reference to obtain SSL key

> Working with multiple keys in key store
> ---------------------------------------
>
>                 Key: WFLY-7158
>                 URL: https://issues.jboss.org/browse/WFLY-7158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:10:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 09:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7158) Working with multiple keys in
	key store
In-Reply-To: <JIRA.12651106.1474433758000@Atlassian.JIRA>
References: <JIRA.12651106.1474433758000@Atlassian.JIRA>
	<JIRA.12651106.1474433758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651106.1474433758000.24356.1487167800483@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363934#comment-13363934 ] 

Jan Kalina edited comment on WFLY-7158 at 2/15/17 9:09 AM:
-----------------------------------------------------------

*Current status:* key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
*Required status:* key-manager use credential-reference to obtain SSL key


was (Author: honza889):
Current status: key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
Required status: key-manager use credential-reference to obtain SSL key

> Working with multiple keys in key store
> ---------------------------------------
>
>                 Key: WFLY-7158
>                 URL: https://issues.jboss.org/browse/WFLY-7158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:16:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Wed, 15 Feb 2017 09:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8070) Messaging subsystem passwords
 and credential-reference should be mutually exclusive
In-Reply-To: <JIRA.12675955.1486729498000@Atlassian.JIRA>
References: <JIRA.12675955.1486729498000@Atlassian.JIRA>
	<JIRA.12675955.1486729498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675955.1486729498000.24471.1487168160516@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363947#comment-13363947 ] 

Tomas Hofman commented on WFLY-8070:
------------------------------------

[~jmesnil] I can take this over, if it's OK with you.

> Messaging subsystem passwords and credential-reference should be mutually exclusive
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-8070
>                 URL: https://issues.jboss.org/browse/WFLY-8070
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Martin Choma
>            Assignee: Jeff Mesnil
>              Labels: user_experience
>
> I don't see any useful use case when I want to configure password attribute in conjuction with credential-reference.
> Please mark password attribute and credential-reference in management model as "alternatives".
> alternatives ? List of string ? Indicates an exclusive relationship between attributes. If this attribute is defined, the other attributes listed in this descriptor's value should be undefined (even if their required descriptor says true; i.e. the presence of this attribute satisfies the requirement.) Default is undefined; i.e. this does not apply to most attributes.
> It applies to:
> * {bridge}
>   ** Attributes {{password}} and {{credential-reference}} should be mutually exclusive.
> * {jms-bridge} 
>   ** Attributes {{source-password}} and {{source-credential-reference}} should be mutually exclusive.  
>   ** Attributes {{target-password}} and {{target-credential-reference}} should be mutually exclusive.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb 15 09:18:00 2017
From: issues at jboss.org (Hans Lund (JIRA))
Date: Wed, 15 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1443) Improve effect of caching
 in ChainedProperties.
In-Reply-To: <JIRA.12676988.1487168226000@Atlassian.JIRA>
References: <JIRA.12676988.1487168226000@Atlassian.JIRA>
	<JIRA.12676988.1487168226168@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676988.1487168226000.24493.1487168280385@Atlassian.JIRA>

Hans Lund created DROOLS-1443:
---------------------------------

             Summary: Improve effect of caching in ChainedProperties.  
                 Key: DROOLS-1443
                 URL: https://issues.jboss.org/browse/DROOLS-1443
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
            Reporter: Hans Lund
            Assignee: Mario Fusco
            Priority: Minor


The ChainedProperties utility has a caching setting that will cache the classpath discovery of property resource - but not the parsing of these resources.

This utility is a hot spot for the initialization of runtime environments - caching the parsed properties instead of the resource url will improve runtime performance.

Changing the caching strategy will make hot changes to classpath property resources impossible. File based property files could be made safe cacheable by investigating file metadata and only read if changed.     



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:18:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 15 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8070) Messaging subsystem passwords
 and credential-reference should be mutually exclusive
In-Reply-To: <JIRA.12675955.1486729498000@Atlassian.JIRA>
References: <JIRA.12675955.1486729498000@Atlassian.JIRA>
	<JIRA.12675955.1486729498000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675955.1486729498000.24504.1487168280787@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-8070:
---------------------------------

    Assignee: Tomas Hofman  (was: Jeff Mesnil)


> Messaging subsystem passwords and credential-reference should be mutually exclusive
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-8070
>                 URL: https://issues.jboss.org/browse/WFLY-8070
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>              Labels: user_experience
>
> I don't see any useful use case when I want to configure password attribute in conjuction with credential-reference.
> Please mark password attribute and credential-reference in management model as "alternatives".
> alternatives ? List of string ? Indicates an exclusive relationship between attributes. If this attribute is defined, the other attributes listed in this descriptor's value should be undefined (even if their required descriptor says true; i.e. the presence of this attribute satisfies the requirement.) Default is undefined; i.e. this does not apply to most attributes.
> It applies to:
> * {bridge}
>   ** Attributes {{password}} and {{credential-reference}} should be mutually exclusive.
> * {jms-bridge} 
>   ** Attributes {{source-password}} and {{source-credential-reference}} should be mutually exclusive.  
>   ** Attributes {{target-password}} and {{target-credential-reference}} should be mutually exclusive.  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Wed Feb 15 09:26:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 09:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2076) Wrong options for
 auto-completion in realms of Elytron security-domain in CLI
In-Reply-To: <JIRA.12661609.1479195091000@Atlassian.JIRA>
References: <JIRA.12661609.1479195091000@Atlassian.JIRA>
	<JIRA.12661609.1479195091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661609.1479195091000.24645.1487168760858@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-2076:
-------------------------------
    Fix Version/s: 3.0.0.Beta1


> Wrong options for auto-completion in realms of Elytron security-domain in CLI
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-2076
>                 URL: https://issues.jboss.org/browse/WFCORE-2076
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Server
>    Affects Versions: 3.0.0.Alpha12
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>              Labels: user_experience
>             Fix For: 3.0.0.Beta1
>
>
> Auto-completion for realm in realms of security-domain provides wrong options. In case when ldap-realm with name ldapName is defined in configuration then also option {{rity-realm.ldapName}} occurs in auto-completion options. I am not able to reproduce this issue with properties-realm. Take a look at Steps to Reproduce for more details.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:27:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8129) Upgrade to Narayana
 5.5.2.Final (from 5.5.1.Final-redhat-1)
In-Reply-To: <JIRA.12676993.1487168769000@Atlassian.JIRA>
References: <JIRA.12676993.1487168769000@Atlassian.JIRA>
	<JIRA.12676993.1487168769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676993.1487168769000.24665.1487168821344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan moved JBEAP-8861 to WFLY-8129:
-----------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8129  (was: JBEAP-8861)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Transactions
                     (was: Transactions)


> Upgrade to Narayana 5.5.2.Final (from 5.5.1.Final-redhat-1)
> -----------------------------------------------------------
>
>                 Key: WFLY-8129
>                 URL: https://issues.jboss.org/browse/WFLY-8129
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Kabir Khan
>            Assignee: Tom Jenkinson
>
> https://issues.jboss.org/browse/JBTM-2848 was found during testing with the new EJB client and is included in this fix



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:27:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 09:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2076) Wrong options for
 auto-completion in realms of Elytron security-domain in CLI
In-Reply-To: <JIRA.12661609.1479195091000@Atlassian.JIRA>
References: <JIRA.12661609.1479195091000@Atlassian.JIRA>
	<JIRA.12661609.1479195091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661609.1479195091000.24676.1487168821652@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13363966#comment-13363966 ] 

Jan Kalina commented on WFCORE-2076:
------------------------------------

Already fixed in wildfly-core 3.0.0.Beta1. Can be closed.

> Wrong options for auto-completion in realms of Elytron security-domain in CLI
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-2076
>                 URL: https://issues.jboss.org/browse/WFCORE-2076
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Server
>    Affects Versions: 3.0.0.Alpha12
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>              Labels: user_experience
>             Fix For: 3.0.0.Beta1
>
>
> Auto-completion for realm in realms of security-domain provides wrong options. In case when ldap-realm with name ldapName is defined in configuration then also option {{rity-realm.ldapName}} occurs in auto-completion options. I am not able to reproduce this issue with properties-realm. Take a look at Steps to Reproduce for more details.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:28:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Wed, 15 Feb 2017 09:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8127) Upgrade Narayana to
	5.5.2.Final
In-Reply-To: <JIRA.12676982.1487167301000@Atlassian.JIRA>
References: <JIRA.12676982.1487167301000@Atlassian.JIRA>
	<JIRA.12676982.1487167301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676982.1487167301000.24684.1487168880672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-8127:
--------------------------------
    Description: 
Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487
https://github.com/jbosstm/narayana/commits/5.5.2.Final
https://github.com/jbosstm/narayana/compare/5.5.1.Final...5.5.2.Final

  was:
Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487
https://github.com/jbosstm/narayana/commits/5.5.2.Final



> Upgrade Narayana to 5.5.2.Final
> -------------------------------
>
>                 Key: WFLY-8127
>                 URL: https://issues.jboss.org/browse/WFLY-8127
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> Release notes: https://issues.jboss.org/projects/JBTM/versions/12333487
> https://github.com/jbosstm/narayana/commits/5.5.2.Final
> https://github.com/jbosstm/narayana/compare/5.5.1.Final...5.5.2.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:29:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8129) Upgrade to Narayana
 5.5.2.Final (from 5.5.1.Final-redhat-1)
In-Reply-To: <JIRA.12676993.1487168769000@Atlassian.JIRA>
References: <JIRA.12676993.1487168769000@Atlassian.JIRA>
	<JIRA.12676993.1487168769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676993.1487168769000.24697.1487168940262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan deleted WFLY-8129:
-----------------------------


> Upgrade to Narayana 5.5.2.Final (from 5.5.1.Final-redhat-1)
> -----------------------------------------------------------
>
>                 Key: WFLY-8129
>                 URL: https://issues.jboss.org/browse/WFLY-8129
>             Project: WildFly
>          Issue Type: Component Upgrade
>            Reporter: Kabir Khan
>            Assignee: Tom Jenkinson
>
> https://issues.jboss.org/browse/JBTM-2848 was found during testing with the new EJB client and is included in this fix



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.24820.1487169364924@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.24824.1487169364996@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta3, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Wed Feb 15 09:36:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.24831.1487169365171@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.24812.1487169364594@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36: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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.24838.1487169365340@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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  Wed Feb 15 09:36:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.24848.1487169365727@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:05 -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: <JIRA.12666705.1481282688000@Atlassian.JIRA>
References: <JIRA.12666705.1481282688000@Atlassian.JIRA>
	<JIRA.12666705.1481282688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666705.1481282688000.24855.1487169365959@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron
	1.1.0.Final
In-Reply-To: <JIRA.12666683.1481279343000@Atlassian.JIRA>
References: <JIRA.12666683.1481279343000@Atlassian.JIRA>
	<JIRA.12666683.1481279343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666683.1481279343000.24862.1487169366144@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.24871.1487169366444@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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 Feb 15 09:36:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.24878.1487169366761@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.24886.1487169366976@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>         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  Wed Feb 15 09:36:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:07 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.24894.1487169367212@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.24905.1487169368104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1964:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta3
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.24897.1487169367840@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta3
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1962) Deprecate
 ParameterValidator.validateResolvedParameter, try and get rid of uses of it
In-Reply-To: <JIRA.12660247.1478625712000@Atlassian.JIRA>
References: <JIRA.12660247.1478625712000@Atlassian.JIRA>
	<JIRA.12660247.1478625712000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660247.1478625712000.24908.1487169368165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1962:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1962
>                 URL: https://issues.jboss.org/browse/WFCORE-1962
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta3
>
>
> The ParameterValidator.validateResolvedParameter method specifies the impl should call ModelNode.resolve() and then validate that. This is a broken contract as ModelNode.resolve() is not the expression resolution mechanism of WildFly.
> This code is only used in a few places. The normal way resolution + validation happens is outside code (e.g. AttributeDefinition) resolves the value and then calls the normal ParameterValidator.validateParameter method.
> So, task here is to look into the few uses of this method in core and full, determine they can be changed to no longer use it, change them, then deprecate this method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.24917.1487169368417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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 Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36: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: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.24912.1487169368298@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>         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<String, String>, 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  Wed Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36: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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.24924.1487169368695@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.24930.1487169368839@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly
 handles duplicate module names
In-Reply-To: <JIRA.12643479.1471302678000@Atlassian.JIRA>
References: <JIRA.12643479.1471302678000@Atlassian.JIRA>
	<JIRA.12643479.1471302678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643479.1471302678000.24943.1487169369198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1717:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
>                 Key: WFCORE-1717
>                 URL: https://issues.jboss.org/browse/WFCORE-1717
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
>            Reporter: Toby Crawley
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta3
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
>    IllegalStateException that occurs when trying to generate the
>    XMLStreamException
>    (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.24938.1487169369091@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36: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: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.24948.1487169369344@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:09 -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: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.24957.1487169369585@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:09 -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: <JIRA.12626950.1463652179000@Atlassian.JIRA>
References: <JIRA.12626950.1463652179000@Atlassian.JIRA>
	<JIRA.12626950.1463652179000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626950.1463652179000.24961.1487169369847@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>         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  Wed Feb 15 09:36:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.24965.1487169369981@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1489:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 3.0.0.Beta3
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1441) Threads resource classes
 should make it easy for users to declare capabilities
In-Reply-To: <JIRA.12610985.1458236449000@Atlassian.JIRA>
References: <JIRA.12610985.1458236449000@Atlassian.JIRA>
	<JIRA.12610985.1458236449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610985.1458236449000.24968.1487169370069@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1441:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Threads resource classes should make it easy for users to declare capabilities
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-1441
>                 URL: https://issues.jboss.org/browse/WFCORE-1441
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta3
>
>
> The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking.
> But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities.
> Things probably needed:
> 1) Ability to declare the capability that should be registered when a resource is created.
> 2) Ability to declare the capability that model reference attributes in a resource refer to.
> Perhaps others, but those are the ones that come immediately to mind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:10 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.24979.1487169370410@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Beta3
>
>         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  Wed Feb 15 09:36:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:10 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.24988.1487169370648@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>         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  Wed Feb 15 09:36:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.24994.1487169370875@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.25002.1487169371128@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> "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.Beta3
>
>
> 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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.25009.1487169371327@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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.<init>(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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.25015.1487169371491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-459:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta3
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.25019.1487169371602@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -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: <JIRA.12469962.1341563495000@Atlassian.JIRA>
References: <JIRA.12469962.1341563495000@Atlassian.JIRA>
	<JIRA.12469962.1341563495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469962.1341563495000.25024.1487169371724@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-377:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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, management
>             Fix For: 3.0.0.Beta3
>
>
> 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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -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: <JIRA.12468578.1339443565000@Atlassian.JIRA>
References: <JIRA.12468578.1339443565000@Atlassian.JIRA>
	<JIRA.12468578.1339443565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468578.1339443565000.25035.1487169371987@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-185:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> 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: rhq
>             Fix For: 3.0.0.Beta3
>
>
> 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  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.25028.1487169371827@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-266:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta3
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.25038.1487169372051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-107:
------------------------------
    Fix Version/s: 3.0.0.Beta3
                       (was: 3.0.0.Beta2)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta3
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:12 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.25044.1487169372296@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:36:12 2017
From: issues at jboss.org (R Searls (JIRA))
Date: Wed, 15 Feb 2017 09:36:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8115) Add integration tests for
	jaxrs
In-Reply-To: <JIRA.12676822.1487098541000@Atlassian.JIRA>
References: <JIRA.12676822.1487098541000@Atlassian.JIRA>
	<JIRA.12676822.1487098541000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676822.1487098541000.25058.1487169372796@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

R Searls reopened WFLY-8115:
----------------------------


submitting new PR

> Add integration tests for jaxrs
> -------------------------------
>
>                 Key: WFLY-8115
>                 URL: https://issues.jboss.org/browse/WFLY-8115
>             Project: WildFly
>          Issue Type: Task
>          Components: REST
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: R Searls
>            Assignee: R Searls
>            Priority: Minor
>
> Add integration tests that preform testing of jaxrs 2.0 spec rules for archive processing.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 09:36:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 15 Feb 2017 09:36:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.24998.1487169371046@Atlassian.JIRA>


     [ 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.Beta3
                       (was: 3.0.0.Beta2)


> 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.Beta3
>
>
> 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  Wed Feb 15 09:54:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Wed, 15 Feb 2017 09:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from
 Tech Preview release to CFME 4.5 release
In-Reply-To: <JIRA.12675308.1486476804000@Atlassian.JIRA>
References: <JIRA.12675308.1486476804000@Atlassian.JIRA>
	<JIRA.12675308.1486476804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675308.1486476804000.25186.1487170440838@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364012#comment-13364012 ] 

Hayk Hovsepyan commented on HAWKULARQE-30:
------------------------------------------

Polarion Test case is added: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10031

> [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  Wed Feb 15 10:18:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 10:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7158) Working with multiple keys in
	key store
In-Reply-To: <JIRA.12651106.1474433758000@Atlassian.JIRA>
References: <JIRA.12651106.1474433758000@Atlassian.JIRA>
	<JIRA.12651106.1474433758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651106.1474433758000.25411.1487171880405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7158:
-----------------------------
    Comment: was deleted

(was: *Current status:* key-manager reference key-store to obtain SSL key, credential-reference is used only to obtain its password
*Required status:* key-manager use credential-reference to obtain SSL key)


> Working with multiple keys in key store
> ---------------------------------------
>
>                 Key: WFLY-7158
>                 URL: https://issues.jboss.org/browse/WFLY-7158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 10:28:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 15 Feb 2017 10:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7158) Working with multiple keys in
	key store
In-Reply-To: <JIRA.12651106.1474433758000@Atlassian.JIRA>
References: <JIRA.12651106.1474433758000@Atlassian.JIRA>
	<JIRA.12651106.1474433758000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651106.1474433758000.25502.1487172481648@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364059#comment-13364059 ] 

Jan Kalina commented on WFLY-7158:
----------------------------------

As the KeyManagerFactory consume KeyStore, there is no reason/possibility to use CredentialReference here. Will add *alias-filter* to the key-manager instead.

> Working with multiple keys in key store
> ---------------------------------------
>
>                 Key: WFLY-7158
>                 URL: https://issues.jboss.org/browse/WFLY-7158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 10:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 10:58: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: <JIRA.12468578.1339443565000@Atlassian.JIRA>
References: <JIRA.12468578.1339443565000@Atlassian.JIRA>
	<JIRA.12468578.1339443565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468578.1339443565000.25743.1487174280408@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-185:
------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta3)


> 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: 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  Wed Feb 15 11:00:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 11:00: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: <JIRA.12469962.1341563495000@Atlassian.JIRA>
References: <JIRA.12469962.1341563495000@Atlassian.JIRA>
	<JIRA.12469962.1341563495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469962.1341563495000.25767.1487174400506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-377:
------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 3.0.0.Beta3)


> 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, 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  Wed Feb 15 11:03:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.25796.1487174580229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1489:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha1
                       (was: 3.0.0.Beta3)


I'm moving this to 4. If there's a clear need for it in 3, please let me know.

> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 4.0.0.Alpha1
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 11:13:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2076) Wrong options for
 auto-completion in realms of Elytron security-domain in CLI
In-Reply-To: <JIRA.12661609.1479195091000@Atlassian.JIRA>
References: <JIRA.12661609.1479195091000@Atlassian.JIRA>
	<JIRA.12661609.1479195091000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661609.1479195091000.25880.1487175180725@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-2076.
--------------------------------------
      Assignee: Tomaz Cerar  (was: Brian Stansberry)
    Resolution: Done


I'm going to guess this is fixed because of something Tomaz did. :)

> Wrong options for auto-completion in realms of Elytron security-domain in CLI
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-2076
>                 URL: https://issues.jboss.org/browse/WFCORE-2076
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Server
>    Affects Versions: 3.0.0.Alpha12
>            Reporter: Ondrej Lukas
>            Assignee: Tomaz Cerar
>              Labels: user_experience
>             Fix For: 3.0.0.Beta1
>
>
> Auto-completion for realm in realms of security-domain provides wrong options. In case when ldap-realm with name ldapName is defined in configuration then also option {{rity-realm.ldapName}} occurs in auto-completion options. I am not able to reproduce this issue with properties-realm. Take a look at Steps to Reproduce for more details.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 12:09:00 2017
From: issues at jboss.org (tech meshter (JIRA))
Date: Wed, 15 Feb 2017 12:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178532000@Atlassian.JIRA>
References: <JIRA.12677036.1487178532000@Atlassian.JIRA>
	<JIRA.12677036.1487178532737@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178532000.26495.1487178540456@Atlassian.JIRA>

tech meshter created DROOLS-1444:
------------------------------------

             Summary: KieSession to implement java.lang.AutoCloseable
                 Key: DROOLS-1444
                 URL: https://issues.jboss.org/browse/DROOLS-1444
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
    Affects Versions: 6.5.0.Final
            Reporter: tech meshter
            Assignee: Mario Fusco
            Priority: Minor


Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 12:11:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 15 Feb 2017 12:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2300)
 ReadResourceNameOperationStepHandler does not check if the resource exists
 before returning the resource name
In-Reply-To: <JIRA.12677037.1487178624000@Atlassian.JIRA>
References: <JIRA.12677037.1487178624000@Atlassian.JIRA>
	<JIRA.12677037.1487178624000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677037.1487178624000.26509.1487178660812@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins moved JBEAP-8868 to WFCORE-2300:
----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2300  (was: JBEAP-8868)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
                           (was: User Experience)
    Affects Version/s:     (was: 7.1.0.DR7)


> ReadResourceNameOperationStepHandler does not check if the resource exists before returning the resource name
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2300
>                 URL: https://issues.jboss.org/browse/WFCORE-2300
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>
> Trying to read the {{category}} attribute on a nonexistent logger results in success:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/logger=aaaaaa:read-attribute(name=category)
> {
>     "outcome" => "success",
>     "result" => "aaaaaa"
> }
> {code}
> Any other attributes can't be read and the operation correctly fails, e.g.:
> {code}
> [standalone at localhost:9990 /] /subsystem=logging/logger=aaaaaab:read-attribute(name=level
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0216: Management resource '[
>     (\"subsystem\" => \"logging\"),
>     (\"logger\" => \"aaaaaab\")
> ]' not found",
>     "rolled-back" => true
> }
> {code}
> This behavior is confusing, the operation should fail for any attribute on a nonexistent logger.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 12:38:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 15 Feb 2017 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8130) Upgrade WildFly Transaction
 Client to 1.0.0.Beta14
In-Reply-To: <JIRA.12677042.1487180248000@Atlassian.JIRA>
References: <JIRA.12677042.1487180248000@Atlassian.JIRA>
	<JIRA.12677042.1487180248188@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677042.1487180248000.26602.1487180280334@Atlassian.JIRA>

Darran Lofthouse created WFLY-8130:
--------------------------------------

             Summary: Upgrade WildFly Transaction Client to 1.0.0.Beta14
                 Key: WFLY-8130
                 URL: https://issues.jboss.org/browse/WFLY-8130
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Transactions
            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 Feb 15 13:14:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 15 Feb 2017 13:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7980) Upgrade mod_cluster to
	1.3.6.CR2
In-Reply-To: <JIRA.12673159.1485429613000@Atlassian.JIRA>
References: <JIRA.12673159.1485429613000@Atlassian.JIRA>
	<JIRA.12673159.1485429613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673159.1485429613000.26685.1487182440290@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7980:
---------------------------------
    Description: https://issues.jboss.org/projects/MODCLUSTER/versions/12333488


> Upgrade mod_cluster to 1.3.6.CR2
> --------------------------------
>
>                 Key: WFLY-7980
>                 URL: https://issues.jboss.org/browse/WFLY-7980
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: mod_cluster
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> https://issues.jboss.org/projects/MODCLUSTER/versions/12333488



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 14:15:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 14:15:00 -0500 (EST)
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: <JIRA.12497139.1374586120000@Atlassian.JIRA>
References: <JIRA.12497139.1374586120000@Atlassian.JIRA>
	<JIRA.12497139.1374586120000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497139.1374586120000.26855.1487186100254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1805:
------------------------------------------
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1422216
        Bugzilla Update: Perform


> 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  Wed Feb 15 14:45:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 15 Feb 2017 14:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores
 should be case insensitive
In-Reply-To: <JIRA.12677059.1487187855000@Atlassian.JIRA>
References: <JIRA.12677059.1487187855000@Atlassian.JIRA>
	<JIRA.12677059.1487187855431@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677059.1487187855000.26923.1487187900299@Atlassian.JIRA>

Josef Cacek created WFLY-8131:
---------------------------------

             Summary: 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: Darran Lofthouse
            Priority: Critical


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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 14:47:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Wed, 15 Feb 2017 14:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores
 should be case insensitive
In-Reply-To: <JIRA.12677059.1487187855000@Atlassian.JIRA>
References: <JIRA.12677059.1487187855000@Atlassian.JIRA>
	<JIRA.12677059.1487187855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677059.1487187855000.26937.1487188020667@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364206#comment-13364206 ] 

Josef Cacek commented on WFLY-8131:
-----------------------------------

Usage in credential references should be also case insensitive.

> 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: Darran Lofthouse
>            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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 16:05:00 2017
From: issues at jboss.org (Vladimir Dosoudil (JIRA))
Date: Wed, 15 Feb 2017 16:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8132) Upgrade picketlink to
	2.5.5.SP6
In-Reply-To: <JIRA.12677071.1487192581000@Atlassian.JIRA>
References: <JIRA.12677071.1487192581000@Atlassian.JIRA>
	<JIRA.12677071.1487192581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677071.1487192581000.27263.1487192700653@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Dosoudil moved JBEAP-8873 to WFLY-8132:
------------------------------------------------

          Project: WildFly  (was: JBoss Enterprise Application Platform)
              Key: WFLY-8132  (was: JBEAP-8873)
         Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
      Component/s: Security
                       (was: Build System)
    Fix Version/s:     (was: 7.1.0.GA)


> Upgrade picketlink to 2.5.5.SP6
> -------------------------------
>
>                 Key: WFLY-8132
>                 URL: https://issues.jboss.org/browse/WFLY-8132
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Vladimir Dosoudil
>            Assignee: Kabir Khan
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 16:05:00 2017
From: issues at jboss.org (Vladimir Dosoudil (JIRA))
Date: Wed, 15 Feb 2017 16:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8132) Upgrade picketlink to
	2.5.5.SP6
In-Reply-To: <JIRA.12677071.1487192581000@Atlassian.JIRA>
References: <JIRA.12677071.1487192581000@Atlassian.JIRA>
	<JIRA.12677071.1487192581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677071.1487192581000.27270.1487192700913@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Dosoudil updated WFLY-8132:
------------------------------------
    Git Pull Request:   (was: https://github.com/jbossas/jboss-eap7/pull/1349)


> Upgrade picketlink to 2.5.5.SP6
> -------------------------------
>
>                 Key: WFLY-8132
>                 URL: https://issues.jboss.org/browse/WFLY-8132
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Vladimir Dosoudil
>            Assignee: Kabir Khan
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 16:05:01 2017
From: issues at jboss.org (Vladimir Dosoudil (JIRA))
Date: Wed, 15 Feb 2017 16:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8132) Upgrade picketlink to
	2.5.5.SP6
In-Reply-To: <JIRA.12677071.1487192581000@Atlassian.JIRA>
References: <JIRA.12677071.1487192581000@Atlassian.JIRA>
	<JIRA.12677071.1487192581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677071.1487192581000.27277.1487192701075@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Dosoudil reassigned WFLY-8132:
---------------------------------------

    Assignee: Vladimir Dosoudil  (was: Kabir Khan)


> Upgrade picketlink to 2.5.5.SP6
> -------------------------------
>
>                 Key: WFLY-8132
>                 URL: https://issues.jboss.org/browse/WFLY-8132
>             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  Wed Feb 15 16:53:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 16:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7885) Persistent calendar timer
 force logging for each invocation if the deployed-class has changed
In-Reply-To: <JIRA.12671015.1484310939000@Atlassian.JIRA>
References: <JIRA.12671015.1484310939000@Atlassian.JIRA>
	<JIRA.12671015.1484310939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671015.1484310939000.27552.1487195580286@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364257#comment-13364257 ] 

RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------

Petr Jurak <pjurak at redhat.com> changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from POST to MODIFIED

> 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  Wed Feb 15 17:48:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 17:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1536) NPE thrown during
 application redeployment, slaves taken offline
In-Reply-To: <JIRA.12618386.1462485726000@Atlassian.JIRA>
References: <JIRA.12618386.1462485726000@Atlassian.JIRA>
	<JIRA.12618386.1462485726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618386.1462485726000.27588.1487198880827@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364264#comment-13364264 ] 

RH Bugzilla Integration commented on WFCORE-1536:
-------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from MODIFIED to ON_QA

> 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  Wed Feb 15 17:48:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 17:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7808) Security subsystem,
 audit provider-module lacks "module" attribute
In-Reply-To: <JIRA.12667964.1481877127000@Atlassian.JIRA>
References: <JIRA.12667964.1481877127000@Atlassian.JIRA>
	<JIRA.12667964.1481877127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667964.1481877127000.27596.1487198881011@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364265#comment-13364265 ] 

RH Bugzilla Integration commented on WFLY-7808:
-----------------------------------------------

Petr Jurak <pjurak at redhat.com> changed the Status of [bug 1392436|https://bugzilla.redhat.com/show_bug.cgi?id=1392436] from POST to MODIFIED

> Security subsystem, audit provider-module lacks "module" attribute
> ------------------------------------------------------------------
>
>                 Key: WFLY-7808
>                 URL: https://issues.jboss.org/browse/WFLY-7808
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 11.0.0.Alpha1
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1392436 :
> When adding a provider module for auditing:
> {code}
> [standalone at orac.usersys.redhat.com:9999 /] /subsystem=security/security-domain=LdapRealm/audit=classic/provider-module=test:add(
> => hit TAB
> code=            module-options=  
> {code}
> There is no attribute "module" which would allow a customer to install a custom module.
> Workaround: custom jar file must be added to the "org.picketbox" module.
> However, this needs to be checked/redone each time a CP is installed making it a big overhead when a customer has many installations.
> Logging as a bug and not an RFE, as the presence of the "module" attribute was expected.
> The "module" attribute is defined in the jboss-as-security and wildfly-security schemas since version 1.1, but it seems to never have been implemented.
> cc [~tfonteyn], [~j_ri]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 17:48:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 17:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1138) Operation
 ("clean-obsolete-content") failed NPE
In-Reply-To: <JIRA.12593210.1447871519000@Atlassian.JIRA>
References: <JIRA.12593210.1447871519000@Atlassian.JIRA>
	<JIRA.12593210.1447871519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593210.1447871519000.27600.1487198881106@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364266#comment-13364266 ] 

RH Bugzilla Integration commented on WFCORE-1138:
-------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1404553|https://bugzilla.redhat.com/show_bug.cgi?id=1404553] from MODIFIED to ON_QA

> Operation ("clean-obsolete-content") failed NPE
> -----------------------------------------------
>
>                 Key: WFCORE-1138
>                 URL: https://issues.jboss.org/browse/WFCORE-1138
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.2.Final
>         Environment: Centos 6.7, OpenJDK 1.7, Wildfly 9.0.1.Final, nginx-plus
> Domain, Full-ha, 2 nodes, one war
>            Reporter: nathan dennis
>            Assignee: ehsavoie Hugonnet
>              Labels: nullpointerexception
>             Fix For: 2.0.2.Final
>
>
> NPE happens randomly knocking the instance off line and has to be restarted.
> [Server:server-one] 13:03:37,900 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.NullPointerException
> [Server:server-one] 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.listLocalContents(ContentRepository.java:428)
> [Server:server-one] 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:390)
> [Server:server-one] 	at org.jboss.as.server.mgmt.domain.RemoteFileRepositoryService.cleanObsoleteContent(RemoteFileRepositoryService.java:160)
> [Server:server-one] 	at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> [Server:server-one] 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:626)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:616)
> [Server:server-one] 	at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> [Server:server-one] 	at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> [Server:server-one] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [Server:server-one] 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [Server:server-one] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [Server:server-one] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one] 
> [Server:server-one] 13:03:37,931 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.NullPointerException 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 17:49:02 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 17:49:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1047) Rollback of undeploy and
 deployment remove will fail
In-Reply-To: <JIRA.12588509.1444429996000@Atlassian.JIRA>
References: <JIRA.12588509.1444429996000@Atlassian.JIRA>
	<JIRA.12588509.1444429996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12588509.1444429996000.27667.1487198942001@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364280#comment-13364280 ] 

RH Bugzilla Integration commented on WFCORE-1047:
-------------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1409644|https://bugzilla.redhat.com/show_bug.cgi?id=1409644] from MODIFIED to ON_QA

> 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  Wed Feb 15 17:49:02 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 17:49:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7808) Security subsystem,
 audit provider-module lacks "module" attribute
In-Reply-To: <JIRA.12667964.1481877127000@Atlassian.JIRA>
References: <JIRA.12667964.1481877127000@Atlassian.JIRA>
	<JIRA.12667964.1481877127000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667964.1481877127000.27675.1487198942206@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364281#comment-13364281 ] 

RH Bugzilla Integration commented on WFLY-7808:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1392436|https://bugzilla.redhat.com/show_bug.cgi?id=1392436] from MODIFIED to ON_QA

> Security subsystem, audit provider-module lacks "module" attribute
> ------------------------------------------------------------------
>
>                 Key: WFLY-7808
>                 URL: https://issues.jboss.org/browse/WFLY-7808
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 11.0.0.Alpha1
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1392436 :
> When adding a provider module for auditing:
> {code}
> [standalone at orac.usersys.redhat.com:9999 /] /subsystem=security/security-domain=LdapRealm/audit=classic/provider-module=test:add(
> => hit TAB
> code=            module-options=  
> {code}
> There is no attribute "module" which would allow a customer to install a custom module.
> Workaround: custom jar file must be added to the "org.picketbox" module.
> However, this needs to be checked/redone each time a CP is installed making it a big overhead when a customer has many installations.
> Logging as a bug and not an RFE, as the presence of the "module" attribute was expected.
> The "module" attribute is defined in the jboss-as-security and wildfly-security schemas since version 1.1, but it seems to never have been implemented.
> cc [~tfonteyn], [~j_ri]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 18:03:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Wed, 15 Feb 2017 18:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8133) Mount point not found
 exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
In-Reply-To: <JIRA.12677075.1487199745000@Atlassian.JIRA>
References: <JIRA.12677075.1487199745000@Atlassian.JIRA>
	<JIRA.12677075.1487199745661@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199745000.27725.1487199780351@Atlassian.JIRA>

Bjoern Stuetz created WFLY-8133:
-----------------------------------

             Summary: Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
                 Key: WFLY-8133
                 URL: https://issues.jboss.org/browse/WFLY-8133
             Project: WildFly
          Issue Type: Bug
          Components: CLI
         Environment: WildFly 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: Jason Greene


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:

{code:java}
java.io.IOException: Mount point not foundImage
    at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
    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 Java or WildFly side; but might need insights on why findMountEntry is invoked.

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  Wed Feb 15 18:21:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 18:21: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.27858.1487200860392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-8133 to WFCORE-2301:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2301  (was: WFLY-8133)
    Component/s: Domain Management
                     (was: CLI)


> 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 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: Jason Greene
>
> 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:
> {code:java}
> java.io.IOException: Mount point not foundImage
>     at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
>     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 Java or WildFly side; but might need insights on why findMountEntry is invoked.
> 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  Wed Feb 15 18:21:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 18:21: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.27862.1487200860506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2301:
----------------------------------------

    Assignee: Brian Stansberry  (was: Jason Greene)


> 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 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
>
> 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:
> {code:java}
> java.io.IOException: Mount point not foundImage
>     at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
>     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 Java or WildFly side; but might need insights on why findMountEntry is invoked.
> 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  Wed Feb 15 18:26:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Wed, 15 Feb 2017 18:26: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.27868.1487201160085@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bjoern Stuetz updated WFCORE-2301:
----------------------------------
    Description: 
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:

{code:java}
java.io.IOException: Mount point not foundImage
    at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
    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.

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

  was:
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:

{code:java}
java.io.IOException: Mount point not foundImage
    at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
    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 Java or WildFly side; but might need insights on why findMountEntry is invoked.

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



> 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 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
>
> 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:
> {code:java}
> java.io.IOException: Mount point not foundImage
>     at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
>     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.
> 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  Wed Feb 15 18:56:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 18:56: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.27925.1487202960091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364306#comment-13364306 ] 

Brian Stansberry commented on WFCORE-2301:
------------------------------------------

Hi [~bjoernstuetztss]. It looks like the stack trace in the description is missing some items, as our code doesn't call  LinuxFileStore.findMountEntry. Do you have the missing bits, and also what WildFly release they come from?

The Stack Overflow entry has that  and it looks like the problem is a call to java.nio.files.File.getFileStore. But I'm not sure if that's the only thing that triggers this. But if that's the only trigger point then it may be easier to work around it.

> 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 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
>
> 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:
> {code:java}
> java.io.IOException: Mount point not foundImage
>     at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
>     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.
> 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  Wed Feb 15 20:49:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 15 Feb 2017 20:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1138) Operation
 ("clean-obsolete-content") failed NPE
In-Reply-To: <JIRA.12593210.1447871519000@Atlassian.JIRA>
References: <JIRA.12593210.1447871519000@Atlassian.JIRA>
	<JIRA.12593210.1447871519000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593210.1447871519000.27991.1487209740169@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364316#comment-13364316 ] 

RH Bugzilla Integration commented on WFCORE-1138:
-------------------------------------------------

Petr Jurak <pjurak at redhat.com> changed the Status of [bug 1404553|https://bugzilla.redhat.com/show_bug.cgi?id=1404553] from POST to MODIFIED

> Operation ("clean-obsolete-content") failed NPE
> -----------------------------------------------
>
>                 Key: WFCORE-1138
>                 URL: https://issues.jboss.org/browse/WFCORE-1138
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 1.0.2.Final
>         Environment: Centos 6.7, OpenJDK 1.7, Wildfly 9.0.1.Final, nginx-plus
> Domain, Full-ha, 2 nodes, one war
>            Reporter: nathan dennis
>            Assignee: ehsavoie Hugonnet
>              Labels: nullpointerexception
>             Fix For: 2.0.2.Final
>
>
> NPE happens randomly knocking the instance off line and has to be restarted.
> [Server:server-one] 13:03:37,900 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.NullPointerException
> [Server:server-one] 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.listLocalContents(ContentRepository.java:428)
> [Server:server-one] 	at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:390)
> [Server:server-one] 	at org.jboss.as.server.mgmt.domain.RemoteFileRepositoryService.cleanObsoleteContent(RemoteFileRepositoryService.java:160)
> [Server:server-one] 	at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:803)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> [Server:server-one] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> [Server:server-one] 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1183)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:626)
> [Server:server-one] 	at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:616)
> [Server:server-one] 	at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> [Server:server-one] 	at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> [Server:server-one] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [Server:server-one] 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [Server:server-one] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [Server:server-one] 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Server:server-one] 
> [Server:server-one] 13:03:37,931 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.NullPointerException 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 21:44:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 21:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8134) Tests using WildflyTestRunner
 are not passing java.net.preferIPv4Stack to servers
In-Reply-To: <JIRA.12677082.1487213013000@Atlassian.JIRA>
References: <JIRA.12677082.1487213013000@Atlassian.JIRA>
	<JIRA.12677082.1487213013101@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677082.1487213013000.28020.1487213040056@Atlassian.JIRA>

Brian Stansberry created WFLY-8134:
--------------------------------------

             Summary: Tests using WildflyTestRunner are not passing java.net.preferIPv4Stack to servers
                 Key: WFLY-8134
                 URL: https://issues.jboss.org/browse/WFLY-8134
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Brian Stansberry


ReadFullModelTestCase and ManagementOnlyModeTestCase are not passing java.net.preferIPv4Stack to the server when -Dipv6 isn't used. This led to the failure at https://ci.wildfly.org/viewLog.html?buildTypeId=WF_MasterIgnoreLinux&buildId=46424



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 21:45:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 21:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8135) Tests using WildflyTestRunner
 are not passing java.net.preferIPv4Stack to servers
In-Reply-To: <JIRA.12677083.1487213094000@Atlassian.JIRA>
References: <JIRA.12677083.1487213094000@Atlassian.JIRA>
	<JIRA.12677083.1487213094182@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677083.1487213094000.28022.1487213100065@Atlassian.JIRA>

Brian Stansberry created WFLY-8135:
--------------------------------------

             Summary: Tests using WildflyTestRunner are not passing java.net.preferIPv4Stack to servers
                 Key: WFLY-8135
                 URL: https://issues.jboss.org/browse/WFLY-8135
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Brian Stansberry


ReadFullModelTestCase and ManagementOnlyModeTestCase are not passing java.net.preferIPv4Stack to the server when -Dipv6 isn't used. This led to the failure at https://ci.wildfly.org/viewLog.html?buildTypeId=WF_MasterIgnoreLinux&buildId=46424



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 15 21:46:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 15 Feb 2017 21:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8134) Tests using WildflyTestRunner
 are not passing java.net.preferIPv4Stack to servers
In-Reply-To: <JIRA.12677082.1487213013000@Atlassian.JIRA>
References: <JIRA.12677082.1487213013000@Atlassian.JIRA>
	<JIRA.12677082.1487213013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677082.1487213013000.28031.1487213160567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-8134:
--------------------------------------

    Assignee: Tomaz Cerar


> Tests using WildflyTestRunner are not passing java.net.preferIPv4Stack to servers
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8134
>                 URL: https://issues.jboss.org/browse/WFLY-8134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>
> ReadFullModelTestCase and ManagementOnlyModeTestCase are not passing java.net.preferIPv4Stack to the server when -Dipv6 isn't used. This led to the failure at https://ci.wildfly.org/viewLog.html?buildTypeId=WF_MasterIgnoreLinux&buildId=46424



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 04:54:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 04:54: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29243.1487238840965@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bjoern Stuetz updated WFCORE-2301:
----------------------------------
    Description: 
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}

{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.<init>(UnixFileStore.java:65)
         at sun.nio.fs.LinuxFileStore.<init>(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

  was:
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:

{code:java}
java.io.IOException: Mount point not foundImage
    at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
    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.

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



> 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 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
>
> 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}
> {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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 04:55:00 2017
From: issues at jboss.org (Andreas Klemp (JIRA))
Date: Thu, 16 Feb 2017 04:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI
	@Stereotype
In-Reply-To: <JIRA.12677166.1487238894000@Atlassian.JIRA>
References: <JIRA.12677166.1487238894000@Atlassian.JIRA>
	<JIRA.12677166.1487238894753@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677166.1487238894000.29247.1487238900225@Atlassian.JIRA>

Andreas Klemp created WFLY-8136:
-----------------------------------

             Summary: 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
    Affects Versions: 9.0.1.Final
         Environment: Windows 7, JDK 1.8.0_60
            Reporter: Andreas Klemp
            Assignee: Stuart Douglas


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  Thu Feb 16 04:56:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 04:56: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29250.1487238960078@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364446#comment-13364446 ] 

Bjoern Stuetz commented on WFCORE-2301:
---------------------------------------

Hi [~brian.stansberry], sorry my bad. Added infos to issue. We found only that part mentioned in issue (cli -> config backup) causing the problem. Cheers! Bjoern

> 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 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
>
> 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}
> {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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 05:07:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 16 Feb 2017 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071266000@Atlassian.JIRA>
References: <JIRA.12676576.1487071266000@Atlassian.JIRA>
	<JIRA.12676576.1487071266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071266000.29376.1487239620060@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-8109:
--------------------------------
    Description: 
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]
* remove usage of TimeoutUtil from TxTestUtil. If -Dts.timeout.factor=200 is used, MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation and MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty fail:
{noformat}
java.lang.AssertionError: Sent and received message does not match at expected way expected:<replying annotation timeout> but was:<null>
	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.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation(MessageDrivenTimeoutTestCase.java:109)

java.lang.AssertionError: No message should be received as mdb timeouted expected null, but was:<replying annotation timeout>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotNull(Assert.java:755)
	at org.junit.Assert.assertNull(Assert.java:737)
	at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty(MessageDrivenTimeoutTestCase.java:126)
{noformat}

This stabilizes TS on slower machines.

  was:
Improve timeouts in AS TS
* JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
* increase timeout in PassivationTestCase
* JspCompilerTestCase should use TimeoutUtil for timeout
* increase timeout in MDBTestCase
* increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]

This stabilizes TS on slower machines.



> Improve timeouts in AS TS
> -------------------------
>
>                 Key: WFLY-8109
>                 URL: https://issues.jboss.org/browse/WFLY-8109
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]
> * remove usage of TimeoutUtil from TxTestUtil. If -Dts.timeout.factor=200 is used, MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation and MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty fail:
> {noformat}
> java.lang.AssertionError: Sent and received message does not match at expected way expected:<replying annotation timeout> but was:<null>
> 	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.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation(MessageDrivenTimeoutTestCase.java:109)
> java.lang.AssertionError: No message should be received as mdb timeouted expected null, but was:<replying annotation timeout>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotNull(Assert.java:755)
> 	at org.junit.Assert.assertNull(Assert.java:737)
> 	at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty(MessageDrivenTimeoutTestCase.java:126)
> {noformat}
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb 16 05:09:00 2017
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 16 Feb 2017 05:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8109) Improve timeouts in AS TS
In-Reply-To: <JIRA.12676576.1487071266000@Atlassian.JIRA>
References: <JIRA.12676576.1487071266000@Atlassian.JIRA>
	<JIRA.12676576.1487071266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676576.1487071266000.29385.1487239740315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-8109:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9648


> Improve timeouts in AS TS
> -------------------------
>
>                 Key: WFLY-8109
>                 URL: https://issues.jboss.org/browse/WFLY-8109
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Improve timeouts in AS TS
> * JMSMessageDrivenBeanTestCase should use TimeoutUtil for timeout
> * increase timeout in PassivationTestCase
> * JspCompilerTestCase should use TimeoutUtil for timeout
> * increase timeout in MDBTestCase
> * increase the default forked process timeout for basic module to hour, [same timeout is used in clustering module|https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clustering/pom.xml#L24]
> * remove usage of TimeoutUtil from TxTestUtil. If -Dts.timeout.factor=200 is used, MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation and MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty fail:
> {noformat}
> java.lang.AssertionError: Sent and received message does not match at expected way expected:<replying annotation timeout> but was:<null>
> 	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.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutAnnotation(MessageDrivenTimeoutTestCase.java:109)
> java.lang.AssertionError: No message should be received as mdb timeouted expected null, but was:<replying annotation timeout>
> 	at org.junit.Assert.fail(Assert.java:88)
> 	at org.junit.Assert.failNotNull(Assert.java:755)
> 	at org.junit.Assert.assertNull(Assert.java:737)
> 	at org.jboss.as.test.integration.ejb.transaction.mdb.timeout.MessageDrivenTimeoutTestCase.transactionTimeoutActivationProperty(MessageDrivenTimeoutTestCase.java:126)
> {noformat}
> This stabilizes TS on slower machines.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb 16 05:10:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 05:10: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29390.1487239800272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bjoern Stuetz updated WFCORE-2301:
----------------------------------
    Environment: 
WildFly via KeyCloak 2.5.1.Final
<eap.version>7.0.0.Beta</eap.version>
<jboss.as.version>7.2.0.Final</jboss.as.version>
<wildfly.version>10.0.0.Final</wildfly.version>

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

  was:
WildFly 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



> 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
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> 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
>
> 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}
> {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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 05:11:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 05:11: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29393.1487239860180@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bjoern Stuetz updated WFCORE-2301:
----------------------------------
    Environment: 
WildFly via KeyCloak 2.5.1.Final

{code:xml}
<eap.version>7.0.0.Beta</eap.version>
<jboss.as.version>7.2.0.Final</jboss.as.version>
<wildfly.version>10.0.0.Final</wildfly.version>
{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

  was:
WildFly via KeyCloak 2.5.1.Final
<eap.version>7.0.0.Beta</eap.version>
<jboss.as.version>7.2.0.Final</jboss.as.version>
<wildfly.version>10.0.0.Final</wildfly.version>

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



> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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
>
> 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}
> {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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 05:13:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 05:13: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29415.1487239980976@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364446#comment-13364446 ] 

Bjoern Stuetz edited comment on WFCORE-2301 at 2/16/17 5:12 AM:
----------------------------------------------------------------

Hi [~brian.stansberry], sorry my bad. Added infos to issue. So far, we only found that part mentioned in issue (cli -> config backup) causing the problem. Cheers! Bjoern


was (Author: bjoernstuetztss):
Hi [~brian.stansberry], sorry my bad. Added infos to issue. We found only that part mentioned in issue (cli -> config backup) causing the problem. Cheers! Bjoern

> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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
>
> 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}
> {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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 05:13:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 05:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-30) [QE] - Upgrade CFME from
 Tech Preview release to CFME 4.5 release
In-Reply-To: <JIRA.12675308.1486476804000@Atlassian.JIRA>
References: <JIRA.12675308.1486476804000@Atlassian.JIRA>
	<JIRA.12675308.1486476804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675308.1486476804000.29438.1487239981804@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364472#comment-13364472 ] 

Hayk Hovsepyan commented on HAWKULARQE-30:
------------------------------------------

BZ is logged: https://bugzilla.redhat.com/show_bug.cgi?id=1422597

> [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  Thu Feb 16 05:14:00 2017
From: issues at jboss.org (Bjoern Stuetz (JIRA))
Date: Thu, 16 Feb 2017 05:14: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.29451.1487240040396@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bjoern Stuetz updated WFCORE-2301:
----------------------------------
    Description: 
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.<init>(UnixFileStore.java:65)
         at sun.nio.fs.LinuxFileStore.<init>(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

  was:
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}

{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.<init>(UnixFileStore.java:65)
         at sun.nio.fs.LinuxFileStore.<init>(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



> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 05:27:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 16 Feb 2017 05:27: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: <JIRA.12677172.1487240782000@Atlassian.JIRA>
References: <JIRA.12677172.1487240782000@Atlassian.JIRA>
	<JIRA.12677172.1487240782348@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677172.1487240782000.29566.1487240820820@Atlassian.JIRA>

Josef Cacek created WFLY-8137:
---------------------------------

             Summary: 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: Darran Lofthouse
            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  Thu Feb 16 06:06:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Feb 2017 06:06:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4211) MBean implementation
 lifecycle methods in MSC threads
In-Reply-To: <JIRA.12560139.1420017512000@Atlassian.JIRA>
References: <JIRA.12560139.1420017512000@Atlassian.JIRA>
	<JIRA.12560139.1420017512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12560139.1420017512000.29847.1487243161015@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364516#comment-13364516 ] 

RH Bugzilla Integration commented on WFLY-4211:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1401637|https://bugzilla.redhat.com/show_bug.cgi?id=1401637] from MODIFIED to ON_QA

> MBean implementation lifecycle methods in MSC threads
> -----------------------------------------------------
>
>                 Key: WFLY-4211
>                 URL: https://issues.jboss.org/browse/WFLY-4211
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 9.0.0.Beta1
>
>
> MBean lifecycle methods should not be invoked from MSC threads, the implementation of these may block the thread, for instance due to a JNDI bind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 06:45:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Thu, 16 Feb 2017 06:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8138) Upgrade Apache CXF to 3.1.10
	(from 3.1.9)
In-Reply-To: <JIRA.12677198.1487245471000@Atlassian.JIRA>
References: <JIRA.12677198.1487245471000@Atlassian.JIRA>
	<JIRA.12677198.1487245471748@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677198.1487245471000.30138.1487245500873@Atlassian.JIRA>

Rostislav Svoboda created WFLY-8138:
---------------------------------------

             Summary: Upgrade Apache CXF to 3.1.10 (from 3.1.9)
                 Key: WFLY-8138
                 URL: https://issues.jboss.org/browse/WFLY-8138
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Web Services
            Reporter: Rostislav Svoboda
            Assignee: Alessio Soldano


Upgrade Apache CXF to 3.1.10 (from 3.1.9)

We need to pick bug fixes like https://github.com/apache/cxf/commit/e30c816fbbaa3c589062d2ae0202fc47ddd7d70b



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 06:50:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Thu, 16 Feb 2017 06:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8138) Upgrade Apache CXF to 3.1.10
	(from 3.1.9)
In-Reply-To: <JIRA.12677198.1487245472000@Atlassian.JIRA>
References: <JIRA.12677198.1487245472000@Atlassian.JIRA>
	<JIRA.12677198.1487245472000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677198.1487245472000.30211.1487245800699@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda updated WFLY-8138:
------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9662


> Upgrade Apache CXF to 3.1.10 (from 3.1.9)
> -----------------------------------------
>
>                 Key: WFLY-8138
>                 URL: https://issues.jboss.org/browse/WFLY-8138
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Alessio Soldano
>
> Upgrade Apache CXF to 3.1.10 (from 3.1.9)
> We need to pick bug fixes like https://github.com/apache/cxf/commit/e30c816fbbaa3c589062d2ae0202fc47ddd7d70b



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 06:50:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Thu, 16 Feb 2017 06:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8138) Upgrade Apache CXF to 3.1.10
	(from 3.1.9)
In-Reply-To: <JIRA.12677198.1487245472000@Atlassian.JIRA>
References: <JIRA.12677198.1487245472000@Atlassian.JIRA>
	<JIRA.12677198.1487245472000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677198.1487245472000.30216.1487245800894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda reassigned WFLY-8138:
---------------------------------------

    Assignee: Rostislav Svoboda  (was: Alessio Soldano)


> Upgrade Apache CXF to 3.1.10 (from 3.1.9)
> -----------------------------------------
>
>                 Key: WFLY-8138
>                 URL: https://issues.jboss.org/browse/WFLY-8138
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Rostislav Svoboda
>
> Upgrade Apache CXF to 3.1.10 (from 3.1.9)
> We need to pick bug fixes like https://github.com/apache/cxf/commit/e30c816fbbaa3c589062d2ae0202fc47ddd7d70b



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 06:50:01 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 16 Feb 2017 06:50:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8139) Add smoke tests for Undertow
 SSL listener backed by Elytron SSL context
In-Reply-To: <JIRA.12677201.1487245703000@Atlassian.JIRA>
References: <JIRA.12677201.1487245703000@Atlassian.JIRA>
	<JIRA.12677201.1487245703000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677201.1487245703000.30222.1487245801090@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek moved JBEAP-8883 to WFLY-8139:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8139  (was: JBEAP-8883)
             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)


> Add smoke tests for Undertow SSL listener backed by Elytron SSL context
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8139
>                 URL: https://issues.jboss.org/browse/WFLY-8139
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Kotek
>            Assignee: Ondrej Kotek
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 08:51:02 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 16 Feb 2017 08:51:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8140) NPE in server log if client's
 password is null
In-Reply-To: <JIRA.12677257.1487253026000@Atlassian.JIRA>
References: <JIRA.12677257.1487253026000@Atlassian.JIRA>
	<JIRA.12677257.1487253026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677257.1487253026000.32459.1487253062476@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-8886 to WFLY-8140:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8140  (was: JBEAP-8886)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                       Security
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR9)
                           (was: 7.1.0.DR11)


> NPE in server log if client's password is null 
> -----------------------------------------------
>
>                 Key: WFLY-8140
>                 URL: https://issues.jboss.org/browse/WFLY-8140
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>              Labels: authentication, eap71_alpha, validation
>
> If standalone JMS client creates connection with username and password where password is {{null}} like:
> {code}
> connectionFactory.createConnection("admin", null);
> {code}
> then server logs NPE:
> {code}
> 13:24:10,567 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: java.lang.NullPointerException
> 	at java.util.Arrays.fill(Arrays.java:2951) [rt.jar:1.8.0_71]
> 	at org.wildfly.security.evidence.PasswordGuessEvidence.destroy(PasswordGuessEvidence.java:53) [wildfly-elytron-1.1.0.Beta16.jar:1.1.0.Beta16]
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:107)
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
> 	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
> 	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}
> Server should log the same error as if wrong password is provided:
> {code}
> 13:23:38,713 ERROR [org.apache.activemq.artemis.core.server] (default I/O-6) AMQ224018: Failed to create session: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: Unable to validate user]
> 	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:144)
> 	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1205)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1128)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 08:52:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 16 Feb 2017 08:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8068) Credential-store attribute
 relative-to doesn't reference path as required
In-Reply-To: <JIRA.12675844.1486669361000@Atlassian.JIRA>
References: <JIRA.12675844.1486669361000@Atlassian.JIRA>
	<JIRA.12675844.1486669361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675844.1486669361000.32481.1487253120653@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8068:
-----------------------------------

    Assignee:     (was: Ilia Vassilev)


> Credential-store attribute relative-to doesn't reference path as required
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8068
>                 URL: https://issues.jboss.org/browse/WFLY-8068
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>
> 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 Feb 16 08:53:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 16 Feb 2017 08:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7970) Elytron keystore type default
	value
In-Reply-To: <JIRA.12673026.1485355874000@Atlassian.JIRA>
References: <JIRA.12673026.1485355874000@Atlassian.JIRA>
	<JIRA.12673026.1485355874000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673026.1485355874000.32510.1487253181368@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7970:
-----------------------------------

    Assignee:     (was: Ilia Vassilev)


> Elytron keystore type default value
> -----------------------------------
>
>                 Key: WFLY-7970
>                 URL: https://issues.jboss.org/browse/WFLY-7970
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>
> 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  Thu Feb 16 08:55:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 16 Feb 2017 08:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7863) Allow expressions in
 credential-reference attributes
In-Reply-To: <JIRA.12670067.1484036478000@Atlassian.JIRA>
References: <JIRA.12670067.1484036478000@Atlassian.JIRA>
	<JIRA.12670067.1484036478000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12670067.1484036478000.32560.1487253300673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7863:
-----------------------------------

    Assignee:     (was: Ilia Vassilev)


> Allow expressions in credential-reference attributes
> ----------------------------------------------------
>
>                 Key: WFLY-7863
>                 URL: https://issues.jboss.org/browse/WFLY-7863
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            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  Thu Feb 16 08:55:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 16 Feb 2017 08:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.32575.1487253301148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-880:
---------------------------------

    Assignee:     (was: Ilia Vassilev)


> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 08:58:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 16 Feb 2017 08:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7956) Coverity static analysis:
 Performace optimalization in map iterating
In-Reply-To: <JIRA.12672890.1485278153000@Atlassian.JIRA>
References: <JIRA.12672890.1485278153000@Atlassian.JIRA>
	<JIRA.12672890.1485278153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672890.1485278153000.32641.1487253481267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7956:
-----------------------------------

    Assignee:     (was: Ilia Vassilev)


> Coverity static analysis: Performace optimalization in map iterating
> --------------------------------------------------------------------
>
>                 Key: WFLY-7956
>                 URL: https://issues.jboss.org/browse/WFLY-7956
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Priority: Minor
>
> Coverity static analysis found iterating over map can be enhanced
> https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=8486751&defectInstanceId=2122705&mergedDefectId=1389593
> Instead of Map.keySet() + Map.get() combo use just Map.entrySet().
>  
> {code:java|title=ElytronHttpExchange#getRequestParameters}
> for (String name : queryParameters.keySet()) {
>     List<String> values = new ArrayList<>(queryParameters.get(name));
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 09:47:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 16 Feb 2017 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399411@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.33307.1487256420447@Atlassian.JIRA>

Tomaz Cerar created WFLY-8141:
---------------------------------

             Summary: CachedConnectionManager add operation excepts no parameters anymore
                 Key: WFLY-8141
                 URL: https://issues.jboss.org/browse/WFLY-8141
             Project: WildFly
          Issue Type: Bug
            Reporter: Tomaz Cerar
            Assignee: Ingo Weiss
            Priority: Critical


Fix for WFLY-2640 broke :add operation for cached-connection-manager
scipts that do

{noformat}
/profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
{noformat}
{noformat}
/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
{noformat}
now fail with
{{Operation 'add' does not expect any property.}}

This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 09:47:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 16 Feb 2017 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.33312.1487256420593@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-8141:
------------------------------
    Affects Version/s: 11.0.0.Alpha1


> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 09:48:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 16 Feb 2017 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.33315.1487256480822@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-8141:
------------------------------
    Component/s: Domain Management
                 JCA


> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:04:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 16 Feb 2017 10:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8142) Review & update
	ejb-multi-server documents
In-Reply-To: <JIRA.12677282.1487257409000@Atlassian.JIRA>
References: <JIRA.12677282.1487257409000@Atlassian.JIRA>
	<JIRA.12677282.1487257409591@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677282.1487257409000.33570.1487257440691@Atlassian.JIRA>

Tomaz Cerar created WFLY-8142:
---------------------------------

             Summary: Review & update ejb-multi-server documents
                 Key: WFLY-8142
                 URL: https://issues.jboss.org/browse/WFLY-8142
             Project: WildFly
          Issue Type: Enhancement
          Components: Quickstarts
            Reporter: Tomaz Cerar
            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 Feb 16 10:11:00 2017
From: issues at jboss.org (Hans Lund (JIRA))
Date: Thu, 16 Feb 2017 10:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1443) Improve effect of caching
 in ChainedProperties.
In-Reply-To: <JIRA.12676988.1487168226000@Atlassian.JIRA>
References: <JIRA.12676988.1487168226000@Atlassian.JIRA>
	<JIRA.12676988.1487168226000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676988.1487168226000.33672.1487257860337@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364828#comment-13364828 ] 

Hans Lund commented on DROOLS-1443:
-----------------------------------

The strategy for caching is based on resource name and classloader. Very often the classloader is a ProjectClassLoader - almost always a new instance. 

As the ProjectClassLoader do not implement equals and hashCode - the cache quickly runs full. 

Implementing hashcode and equals on the ProjectClassLoader and the InMemoryResourceProvider have in test reduced the number of entries in the cache to less than 1% (from +8k entries to 64).
 


> Improve effect of caching in ChainedProperties.  
> -------------------------------------------------
>
>                 Key: DROOLS-1443
>                 URL: https://issues.jboss.org/browse/DROOLS-1443
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Hans Lund
>            Assignee: Mario Fusco
>            Priority: Minor
>
> The ChainedProperties utility has a caching setting that will cache the classpath discovery of property resource - but not the parsing of these resources.
> This utility is a hot spot for the initialization of runtime environments - caching the parsed properties instead of the resource url will improve runtime performance.
> Changing the caching strategy will make hot changes to classpath property resources impossible. File based property files could be made safe cacheable by investigating file metadata and only read if changed.     



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:30:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 10:30: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: <JIRA.12677290.1487258960000@Atlassian.JIRA>
References: <JIRA.12677290.1487258960000@Atlassian.JIRA>
	<JIRA.12677290.1487258960324@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677290.1487258960000.33795.1487259000366@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2302:
----------------------------------------

             Summary: 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.Beta3






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:49:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 10:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.33950.1487260140218@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364868#comment-13364868 ] 

Brian Stansberry commented on WFLY-8141:
----------------------------------------

We are using this in quickstarts?

AIUI that op never worked. The subsystem adds the resource at boot so any subsequent invocation should have produced a failure.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:54:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Thu, 16 Feb 2017 10:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.33975.1487260440303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364871#comment-13364871 ] 

Martin Simka commented on WFLY-8141:
------------------------------------

it it is used in domain mode, when adding new profile from scratch - [install-domain.cli|https://github.com/wildfly/quickstart/blob/11.x/ejb-multi-server/install-domain.cli]


> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:58:00 2017
From: issues at jboss.org (Stephen Fikes (JIRA))
Date: Thu, 16 Feb 2017 10:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5685) Register management resources
 for deployment-specific caches
In-Reply-To: <JIRA.12592849.1447670888000@Atlassian.JIRA>
References: <JIRA.12592849.1447670888000@Atlassian.JIRA>
	<JIRA.12592849.1447670888000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12592849.1447670888000.34012.1487260680394@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364875#comment-13364875 ] 

Stephen Fikes commented on WFLY-5685:
-------------------------------------

Stats such as the following are accessible via JMX but not via CLI:

averageReadTime
averageWriteTime
elapsedTime
evictions
hitRatio
hits
misses
numberOfEntries
readWriteRatio
removeHits
removeMisses
stores
timeSinceReset

> 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.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 10:59:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 16 Feb 2017 10:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8143) Empty secret-value is not
 allowed in credential stores
In-Reply-To: <JIRA.12677298.1487260714000@Atlassian.JIRA>
References: <JIRA.12677298.1487260714000@Atlassian.JIRA>
	<JIRA.12677298.1487260714577@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677298.1487260714000.34041.1487260741625@Atlassian.JIRA>

Josef Cacek created WFLY-8143:
---------------------------------

             Summary: Empty  secret-value is not allowed in credential stores
                 Key: WFLY-8143
                 URL: https://issues.jboss.org/browse/WFLY-8143
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse
            Priority: Critical


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  Thu Feb 16 11:02:01 2017
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Thu, 16 Feb 2017 11:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.34092.1487260921663@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Spyrko-?mietanko reassigned WFLY-3858:
----------------------------------------------

    Assignee: Bartosz Spyrko-?mietanko  (was: Darran Lofthouse)


> 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: Bartosz Spyrko-?mietanko
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> 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<Map, Principal> cm = (CacheableManager<Map, Principal>) 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 Feb 16 11:07:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 11:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.34174.1487261221427@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364889#comment-13364889 ] 

Brian Stansberry commented on WFLY-8141:
----------------------------------------

Thanks, [~simkam].

FWIW, I wrote this to [~maeste] and [~aloubyansky] a week or so ago in relation to a different problem this resource causes:

---------------------

Hi guys,

This is a follow up to the chat Alexey and I had about the CCM resource earlier today.

Basic summary is the RA subsystem parser ensures that an add op for the CCM resource is always part of the boot ops, so if the JCA subsystem has been parsed, there?s automatically a CCM resource. And the user can?t remove and readd it.

The current situation (which dates to the beginning I guess) violates the requirement that you don?t have to use xml editing to configure. You can?t start with a config with no JCA subsystem, then via the CLI add it and then configure the CCM resource. At least not without a reload in the middle.

Not having to us xml to configure has always been a requirement but with the offline CLI and the new provisioning stuff based on it, it?s an even stronger requirement now.

I see a couple options:

1)
a) Make the CCM add op public again, 
b) Drop the automatic add from the parser. Parser only creates the add op if the xml configures it
c) Have JcaSubsystemAdd add a step that checks if the CCM resource exists (in case user configured it in xml or in the same composite that adds subsystem=jca) and if not that step in turn adds a step that executes the CachedConnectionManagerAdd op with the default params
d) Make CachedConnectionManagerRemove a normal remove again; removes the resource and requires reload

2) Add a parameter to the JCASubsystemAdd op. Complex object, fields are the same as the attributes in the CCM resource. Users can configure CCM when adding the JCA subsystem by setting this parameter. If present, JCASubsystemAdd takes the values in the param and adds a step that executes the CachedConnectionManagerAdd op.

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat

--------------

Since the add op was actually useful in domain mode, it seems like 1) is what we need to do. Otherwise we've introduced an incompatible API change. Removing it was based on my mistaken belief that it was a useless operation.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb 16 11:32:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 16 Feb 2017 11:32:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8144) Removing and re-adding alias
 to credential store leads to Duplicate resource failure
In-Reply-To: <JIRA.12677306.1487262693000@Atlassian.JIRA>
References: <JIRA.12677306.1487262693000@Atlassian.JIRA>
	<JIRA.12677306.1487262693261@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677306.1487262693000.34375.1487262721041@Atlassian.JIRA>

Josef Cacek created WFLY-8144:
---------------------------------

             Summary: Removing and re-adding alias to credential store leads to Duplicate resource failure
                 Key: WFLY-8144
                 URL: https://issues.jboss.org/browse/WFLY-8144
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse
            Priority: Critical


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  Thu Feb 16 11:32:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Thu, 16 Feb 2017 11:32:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8144) Removing and re-adding alias
 to credential store leads to Duplicate resource failure
In-Reply-To: <JIRA.12677306.1487262693000@Atlassian.JIRA>
References: <JIRA.12677306.1487262693000@Atlassian.JIRA>
	<JIRA.12677306.1487262693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677306.1487262693000.34386.1487262721446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-8144:
------------------------------
    Labels: credential-store  (was: )


> Removing and re-adding alias to credential store leads to Duplicate resource failure
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-8144
>                 URL: https://issues.jboss.org/browse/WFLY-8144
>             Project: WildFly
>          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  Thu Feb 16 12:05:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Feb 2017 12:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5274) EJB IOR contains wrong port
 (non-SSL port) information when SSL is required
In-Reply-To: <JIRA.12583908.1441311342000@Atlassian.JIRA>
References: <JIRA.12583908.1441311342000@Atlassian.JIRA>
	<JIRA.12583908.1441311342000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583908.1441311342000.34623.1487264700707@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364936#comment-13364936 ] 

RH Bugzilla Integration commented on WFLY-5274:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1259902|https://bugzilla.redhat.com/show_bug.cgi?id=1259902] from MODIFIED to ON_QA

> 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 Feb 16 12:06:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Feb 2017 12:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1401) JBAS015893: Encountered
 invalid class name message when class name is perfectly valid
In-Reply-To: <JIRA.12492856.1369719391000@Atlassian.JIRA>
References: <JIRA.12492856.1369719391000@Atlassian.JIRA>
	<JIRA.12492856.1369719391000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492856.1369719391000.34626.1487264760376@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364937#comment-13364937 ] 

RH Bugzilla Integration commented on WFLY-1401:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1408846|https://bugzilla.redhat.com/show_bug.cgi?id=1408846] from MODIFIED to ON_QA

> JBAS015893: Encountered invalid class name message when class name is perfectly valid
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-1401
>                 URL: https://issues.jboss.org/browse/WFLY-1401
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>
> The JVM is much more lenient than java as far as class names are concerned, we should probably just get rid of this message altogether. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 12:06:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 16 Feb 2017 12:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied
 dependencies on hot deploy of app using module-alias as dependency
In-Reply-To: <JIRA.12627319.1463846078000@Atlassian.JIRA>
References: <JIRA.12627319.1463846078000@Atlassian.JIRA>
	<JIRA.12627319.1463846078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627319.1463846078000.34631.1487264760536@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364938#comment-13364938 ] 

RH Bugzilla Integration commented on WFLY-6636:
-----------------------------------------------

Vladimir Dosoudil <dosoudil at redhat.com> changed the Status of [bug 1338093|https://bugzilla.redhat.com/show_bug.cgi?id=1338093] from MODIFIED to ON_QA

> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6636
>                 URL: https://issues.jboss.org/browse/WFLY-6636
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Tomas Hofman
>         Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below.  Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
>     <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>     <sub-deployment name="ejb1.jar">
>         <module-alias name="deployment.ejb1"/>
>     </sub-deployment>
>     <sub-deployment name="ejb2.jar">
>         <dependencies>
> <!-- works
>             <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with  WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
>             <module name="deployment.ejb1" slot="main"/>
>         </dependencies>
>     </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".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: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
>   at test.TestEJB2.test1(TestEJB2.java:0)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> 	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> 	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> 	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> 	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)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
>   at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 12:24:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 12:24: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.34753.1487265840135@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13364952#comment-13364952 ] 

Brian Stansberry edited comment on WFCORE-2301 at 2/16/17 12:23 PM:
--------------------------------------------------------------------

I think https://github.com/wildfly/wildfly-core/pull/2188 should work around this by dealing with the failure in Files.getFileStore(Path). We call this in four places in WildFly. This fixes two, the ones involved in your report. Lucene calls it as well in some util, but catches exceptions. The fourth is a management operation handler for an operation CLI/console users can use to learn about space available on the FS (PathInfoHandler). I left that as is, since no one is required to invoke that op and if it fails it seems reasonable that the user sees that.



was (Author: brian.stansberry):
I think https://github.com/wildfly/wildfly-core/pull/2188 should work around this by dealing with the failure in Files.getFileStore(Path). We call this in four places places in WildFly. This fixes two, the ones involved in your report. Lucene calls it as well in some util, but catches exceptions. The fourth is a management operation handler for an operation CLI/console users can use to learn about space available on the FS (PathInfoHandler). I left that as is, since no one is required to invoke that op and if it fails it seems reasonable that the user sees that.

> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Thu Feb 16 12:38:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8134) Tests using WildflyTestRunner
 are not passing java.net.preferIPv4Stack to servers
In-Reply-To: <JIRA.12677082.1487213013000@Atlassian.JIRA>
References: <JIRA.12677082.1487213013000@Atlassian.JIRA>
	<JIRA.12677082.1487213013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677082.1487213013000.34815.1487266680494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8134:
-----------------------------------
    Priority: Critical  (was: Major)


I'm bumping this one to Critical as ReadFullModelTestCase is a kind of "catch problems with a wide net" smoke test so we need to be sure it's enabled. Currently it's disabled when -Dipv6 is not used.

> Tests using WildflyTestRunner are not passing java.net.preferIPv4Stack to servers
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8134
>                 URL: https://issues.jboss.org/browse/WFLY-8134
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> ReadFullModelTestCase and ManagementOnlyModeTestCase are not passing java.net.preferIPv4Stack to the server when -Dipv6 isn't used. This led to the failure at https://ci.wildfly.org/viewLog.html?buildTypeId=WF_MasterIgnoreLinux&buildId=46424



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:31:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-38) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12677336.1487269840000@Atlassian.JIRA>
References: <JIRA.12677336.1487269840000@Atlassian.JIRA>
	<JIRA.12677336.1487269840175@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677336.1487269840000.35049.1487269860640@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-38:
----------------------------------------

             Summary: Manual Testcases - Create and Run
                 Key: HAWKULARQE-38
                 URL: https://issues.jboss.org/browse/HAWKULARQE-38
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user


Create manual testcases if not exists.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:31:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment
In-Reply-To: <JIRA.12677335.1487269803000@Atlassian.JIRA>
References: <JIRA.12677335.1487269803000@Atlassian.JIRA>
	<JIRA.12677335.1487269803772@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677335.1487269803000.35044.1487269860400@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-37:
----------------------------------------

             Summary: Server Group Deployment
                 Key: HAWKULARQE-37
                 URL: https://issues.jboss.org/browse/HAWKULARQE-37
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:32:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-39) Automate testcases
In-Reply-To: <JIRA.12677337.1487269867000@Atlassian.JIRA>
References: <JIRA.12677337.1487269867000@Atlassian.JIRA>
	<JIRA.12677337.1487269867692@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677337.1487269867000.35051.1487269920212@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-39:
----------------------------------------

             Summary: Automate testcases
                 Key: HAWKULARQE-39
                 URL: https://issues.jboss.org/browse/HAWKULARQE-39
             Project: Hawkular QE
          Issue Type: Sub-task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:33:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-40) XA Datasource creation
In-Reply-To: <JIRA.12677338.1487269932000@Atlassian.JIRA>
References: <JIRA.12677338.1487269932000@Atlassian.JIRA>
	<JIRA.12677338.1487269932341@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677338.1487269932000.35062.1487269980059@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-40:
----------------------------------------

             Summary: 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:36:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138105@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.35071.1487270160252@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-41:
----------------------------------------

             Summary: Hawkular Agent for EAP7.1
                 Key: HAWKULARQE-41
                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Hayk Hovsepyan
            Assignee: mfoley user


Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:42:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-42) Treat EAP immutable if
 running in Container
In-Reply-To: <JIRA.12677340.1487270316000@Atlassian.JIRA>
References: <JIRA.12677340.1487270316000@Atlassian.JIRA>
	<JIRA.12677340.1487270316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677340.1487270316000.35103.1487270520463@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan moved HAWKULAR-1203 to HAWKULARQE-42:
----------------------------------------------------

     Project: Hawkular QE  (was: Hawkular)
         Key: HAWKULARQE-42  (was: HAWKULAR-1203)
    Workflow: GIT Pull Request workflow   (was: HAWKULAR workflow v2)


> Treat EAP immutable if running in Container
> -------------------------------------------
>
>                 Key: HAWKULARQE-42
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-42
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>
> See https://issues.jboss.org/browse/HAWKULAR-1183



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:42:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 16 Feb 2017 13:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-42) Treat EAP immutable if
 running in Container
In-Reply-To: <JIRA.12677340.1487270316000@Atlassian.JIRA>
References: <JIRA.12677340.1487270316000@Atlassian.JIRA>
	<JIRA.12677340.1487270316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677340.1487270316000.35113.1487270520850@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan closed HAWKULARQE-42.
------------------------------------
    Resolution: Duplicate Issue


> Treat EAP immutable if running in Container
> -------------------------------------------
>
>                 Key: HAWKULARQE-42
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-42
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>
> See https://issues.jboss.org/browse/HAWKULAR-1183



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 13:53:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 13:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-966) Release WildFly Elytron
	1.1.0.Beta26
In-Reply-To: <JIRA.12677361.1487271160000@Atlassian.JIRA>
References: <JIRA.12677361.1487271160000@Atlassian.JIRA>
	<JIRA.12677361.1487271160991@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677361.1487271160000.35244.1487271180668@Atlassian.JIRA>

Darran Lofthouse created ELY-966:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta26
                 Key: ELY-966
                 URL: https://issues.jboss.org/browse/ELY-966
             Project: WildFly Elytron
          Issue Type: Component Upgrade
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta26






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2303) Upgrade to WildFly Elytron
	1.1.0.Beta26
In-Reply-To: <JIRA.12677379.1487272496000@Atlassian.JIRA>
References: <JIRA.12677379.1487272496000@Atlassian.JIRA>
	<JIRA.12677379.1487272496259@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677379.1487272496000.35439.1487272500358@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2303:
----------------------------------------

             Summary: Upgrade to WildFly Elytron 1.1.0.Beta26
                 Key: WFCORE-2303
                 URL: https://issues.jboss.org/browse/WFCORE-2303
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta3






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-966) Release WildFly Elytron
	1.1.0.Beta26
In-Reply-To: <JIRA.12677361.1487271161000@Atlassian.JIRA>
References: <JIRA.12677361.1487271161000@Atlassian.JIRA>
	<JIRA.12677361.1487271161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677361.1487271161000.35436.1487272500297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-966:
---------------------------------
    Issue Type: Task  (was: Component Upgrade)


> Release WildFly Elytron 1.1.0.Beta26
> ------------------------------------
>
>                 Key: ELY-966
>                 URL: https://issues.jboss.org/browse/ELY-966
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:17:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2304) Upgrade to Elytron Web
	1.0.0.Beta9
In-Reply-To: <JIRA.12677380.1487272561000@Atlassian.JIRA>
References: <JIRA.12677380.1487272561000@Atlassian.JIRA>
	<JIRA.12677380.1487272561156@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677380.1487272561000.35454.1487272620396@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2304:
----------------------------------------

             Summary: Upgrade to Elytron Web 1.0.0.Beta9
                 Key: WFCORE-2304
                 URL: https://issues.jboss.org/browse/WFCORE-2304
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta3






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:17:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2304) Upgrade to Elytron Web
	1.0.0.Beta11
In-Reply-To: <JIRA.12677380.1487272561000@Atlassian.JIRA>
References: <JIRA.12677380.1487272561000@Atlassian.JIRA>
	<JIRA.12677380.1487272561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677380.1487272561000.35471.1487272620833@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2304:
-------------------------------------
    Summary: Upgrade to Elytron Web 1.0.0.Beta11  (was: Upgrade to Elytron Web 1.0.0.Beta9)


> Upgrade to Elytron Web 1.0.0.Beta11
> -----------------------------------
>
>                 Key: WFCORE-2304
>                 URL: https://issues.jboss.org/browse/WFCORE-2304
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta3
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:19:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8145) Upgrade to Elytron Subsystem
	1.0.0.Beta9
In-Reply-To: <JIRA.12677381.1487272696000@Atlassian.JIRA>
References: <JIRA.12677381.1487272696000@Atlassian.JIRA>
	<JIRA.12677381.1487272696042@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677381.1487272696000.35474.1487272740335@Atlassian.JIRA>

Darran Lofthouse created WFLY-8145:
--------------------------------------

             Summary: Upgrade to Elytron Subsystem 1.0.0.Beta9
                 Key: WFLY-8145
                 URL: https://issues.jboss.org/browse/WFLY-8145
             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 Feb 16 14:53:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-966) Release WildFly Elytron
	1.1.0.Beta26
In-Reply-To: <JIRA.12677361.1487271161000@Atlassian.JIRA>
References: <JIRA.12677361.1487271161000@Atlassian.JIRA>
	<JIRA.12677361.1487271161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677361.1487271161000.35584.1487274780217@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-966.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta26
> ------------------------------------
>
>                 Key: ELY-966
>                 URL: https://issues.jboss.org/browse/ELY-966
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta26
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12676714.1487086966000@Atlassian.JIRA>
References: <JIRA.12676714.1487086966000@Atlassian.JIRA>
	<JIRA.12676714.1487086966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676714.1487086966000.35588.1487274843324@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> Presently events could be dropped.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues
In-Reply-To: <JIRA.12676713.1487086905000@Atlassian.JIRA>
References: <JIRA.12676713.1487086905000@Atlassian.JIRA>
	<JIRA.12676713.1487086905000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676713.1487086905000.35591.1487274843386@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation
In-Reply-To: <JIRA.12676712.1487086827000@Atlassian.JIRA>
References: <JIRA.12676712.1487086827000@Atlassian.JIRA>
	<JIRA.12676712.1487086827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676712.1487086827000.35594.1487274843449@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign
 priorities to audit events
In-Reply-To: <JIRA.12676711.1487086785000@Atlassian.JIRA>
References: <JIRA.12676711.1487086785000@Atlassian.JIRA>
	<JIRA.12676711.1487086785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676711.1487086785000.35597.1487274843543@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within
	HTTP API
In-Reply-To: <JIRA.12676078.1486812681000@Atlassian.JIRA>
References: <JIRA.12676078.1486812681000@Atlassian.JIRA>
	<JIRA.12676078.1486812681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676078.1486812681000.35603.1487274843710@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of
 CLIENT_CERT authentication for SASL
In-Reply-To: <JIRA.12675877.1486693276000@Atlassian.JIRA>
References: <JIRA.12675877.1486693276000@Atlassian.JIRA>
	<JIRA.12675877.1486693276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675877.1486693276000.35615.1487274843988@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication
 client has no trust configuration
In-Reply-To: <JIRA.12675878.1486694187000@Atlassian.JIRA>
References: <JIRA.12675878.1486694187000@Atlassian.JIRA>
	<JIRA.12675878.1486694187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675878.1486694187000.35612.1487274843909@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.35618.1487274844121@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.35621.1487274844180@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.35628.1487274844318@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.35634.1487274844534@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events
In-Reply-To: <JIRA.12676710.1487086731000@Atlassian.JIRA>
References: <JIRA.12676710.1487086731000@Atlassian.JIRA>
	<JIRA.12676710.1487086731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676710.1487086731000.35600.1487274843644@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.35641.1487274844723@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.35631.1487274844374@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support
 standard KeyManager instances
In-Reply-To: <JIRA.12675881.1486695345000@Atlassian.JIRA>
References: <JIRA.12675881.1486695345000@Atlassian.JIRA>
	<JIRA.12675881.1486695345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675881.1486695345000.35606.1487274843785@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.35637.1487274844630@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication
 client should not mandate an input source
In-Reply-To: <JIRA.12675879.1486694444000@Atlassian.JIRA>
References: <JIRA.12675879.1486694444000@Atlassian.JIRA>
	<JIRA.12675879.1486694444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675879.1486694444000.35609.1487274843847@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.35625.1487274844261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.1.0.Beta27
                       (was: 1.1.0.Beta26)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta27
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.35644.1487274844791@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.35650.1487274844983@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.35647.1487274844890@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.35670.1487274845743@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.Beta27
>
>
> 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 Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.35662.1487274845358@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.35655.1487274845143@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.35666.1487274845590@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.35679.1487274846037@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.35673.1487274845864@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.35659.1487274845275@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.35683.1487274846206@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.35686.1487274846316@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.35690.1487274846434@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.35696.1487274846600@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.35693.1487274846490@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.35703.1487274846762@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.35710.1487274846908@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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
>             Fix For: 1.1.0.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.35713.1487274846963@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.35717.1487274847035@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.35722.1487274847179@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.35731.1487274847427@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.35725.1487274847271@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.35728.1487274847335@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.35734.1487274847483@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.35738.1487274847559@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.35741.1487274847663@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.35744.1487274847779@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54: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: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.35747.1487274847854@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.35753.1487274847968@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.35758.1487274848055@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:07 -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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.35750.1487274847912@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.35761.1487274848120@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.35765.1487274848186@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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 Feb 16 14:54:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.35768.1487274848243@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.35771.1487274848356@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:05 -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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.35676.1487274845933@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.35706.1487274846821@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 14:54:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 14:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.35700.1487274846680@Atlassian.JIRA>


     [ 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.Beta27
                       (was: 1.1.0.Beta26)


> 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.Beta27
>
>
> 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 Feb 16 15:46:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 15:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2257) Missing username in LDAP
 entry for legacy ldap realm returns 500 instead of 401
In-Reply-To: <JIRA.12674305.1486019615000@Atlassian.JIRA>
References: <JIRA.12674305.1486019615000@Atlassian.JIRA>
	<JIRA.12674305.1486019615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674305.1486019615000.36040.1487277961379@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-2257.
--------------------------------------
    Fix Version/s: 3.0.0.Beta3
       Resolution: Duplicate Issue


> Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-2257
>                 URL: https://issues.jboss.org/browse/WFCORE-2257
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta3
>
>
> In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from WildFly 10 where status code 401 is returned.
> This issue can be related to WFCORE-2258 (500 return for nonexistent user in legacy ldap security realm).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 15:47:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 16 Feb 2017 15:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2258) 500 return for nonexistent
 user in legacy ldap security realm
In-Reply-To: <JIRA.12674306.1486019644000@Atlassian.JIRA>
References: <JIRA.12674306.1486019644000@Atlassian.JIRA>
	<JIRA.12674306.1486019644000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674306.1486019644000.36051.1487278020316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2258:
-------------------------------------
    Fix Version/s: 3.0.0.Beta3


> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
>                 Key: WFCORE-2258
>                 URL: https://issues.jboss.org/browse/WFCORE-2258
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: regression
>             Fix For: 3.0.0.Beta3
>
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN  [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code} 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 15:48:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 16 Feb 2017 15:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8146) Local async EJB invocations
 can be completed before the caller has been notified they are async
In-Reply-To: <JIRA.12677388.1487278048000@Atlassian.JIRA>
References: <JIRA.12677388.1487278048000@Atlassian.JIRA>
	<JIRA.12677388.1487278048000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677388.1487278048000.36061.1487278080552@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-8897 to WFLY-8146:
---------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8146  (was: JBEAP-8897)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: EJB
                     (was: EJB)


> Local async EJB invocations can be completed before the caller has been notified they are async
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8146
>                 URL: https://issues.jboss.org/browse/WFLY-8146
>             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  Thu Feb 16 16:17:01 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 16 Feb 2017 16:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8147) Possible leak of unclosed
 Statement in DatabaseTimerPersistence
In-Reply-To: <JIRA.12677395.1487279767000@Atlassian.JIRA>
References: <JIRA.12677395.1487279767000@Atlassian.JIRA>
	<JIRA.12677395.1487279767000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677395.1487279767000.36289.1487279821300@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-8898 to WFLY-8147:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8147  (was: JBEAP-8898)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: EJB
                           (was: EJB)
    Affects Version/s:     (was: 7.1.0.DR12)


> Possible leak of unclosed Statement in DatabaseTimerPersistence
> ---------------------------------------------------------------
>
>                 Key: WFLY-8147
>                 URL: https://issues.jboss.org/browse/WFLY-8147
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> https://github.com/jbossas/jboss-eap7/blob/EAP_7.1.0.DR12-dev-2/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/persistence/database/DatabaseTimerPersistence.java#L457
> On line 445, a {{Statement}} is obtained, but on line 457 the reference to it can be overwritten, in which case the {{finally}} block on line 496 won't close the previous {{Statement}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 16:37:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 16:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015380@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.36442.1487281020185@Atlassian.JIRA>

Brian Stansberry created WFLY-8148:
--------------------------------------

             Summary: 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}

Server log ERROR which explains why the JNDI lookup fails:

{code}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "app2.ear")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "app2.ear" was rolled back with the following failure message: 
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
{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  Thu Feb 16 16:58:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 16 Feb 2017 16:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-146) Suppressed exception format
 is not correct
In-Reply-To: <JIRA.12673311.1485465008000@Atlassian.JIRA>
References: <JIRA.12673311.1485465008000@Atlassian.JIRA>
	<JIRA.12673311.1485465008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673311.1485465008000.36473.1487282280094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-146:
---------------------------------
    Git Pull Request: https://github.com/jboss-logging/jboss-logmanager/pull/102, https://github.com/jboss-logging/jboss-logmanager/pull/103  (was: https://github.com/jboss-logging/jboss-logmanager/pull/102)


> Suppressed exception format is not correct
> ------------------------------------------
>
>                 Key: LOGMGR-146
>                 URL: https://issues.jboss.org/browse/LOGMGR-146
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>
> The suppressed exception format is not correct when multiple exceptions are suppressed. Too many causes are printed likely because the circular dependencies are not working correctly.
> {code:java|title=Example Reproducer}
> final RuntimeException r1 = new RuntimeException("Exception 1");
> final RuntimeException r2 = new RuntimeException("Exception 2", r1);
> final RuntimeException r3 = new RuntimeException("Exception 3", r2);
> final RuntimeException cause = new RuntimeException("This is the cause", r1);
> cause.addSuppressed(r2);
> cause.addSuppressed(r3);
> Logger.getLogger(Main.class).error("Log message", cause);
> {code}
> {code:title=Output from JBoss Log Manager}
> 13:03:53,684 ERROR [com.jamezp.test.Main] Log message: java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> Caused by: java.lang.RuntimeException: Exception 1
> 	at com.jamezp.test.Main.main(Main.java:161)
> 	... 5 more
> {code}
> {code:title=Output from Throwable.printStackTrace()}
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}
> {code:title=Output from JUL}
> Jan 26, 2017 1:06:29 PM com.jamezp.test.Main main
> ERROR: Log message
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 17:09:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 16 Feb 2017 17:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-146) Suppressed exception format
 is not correct
In-Reply-To: <JIRA.12673311.1485465008000@Atlassian.JIRA>
References: <JIRA.12673311.1485465008000@Atlassian.JIRA>
	<JIRA.12673311.1485465008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673311.1485465008000.36510.1487282940635@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-146:
---------------------------------
    Fix Version/s: 2.0.5.Final
                   2.1.0.Beta1


> Suppressed exception format is not correct
> ------------------------------------------
>
>                 Key: LOGMGR-146
>                 URL: https://issues.jboss.org/browse/LOGMGR-146
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>             Fix For: 2.0.5.Final, 2.1.0.Beta1
>
>
> The suppressed exception format is not correct when multiple exceptions are suppressed. Too many causes are printed likely because the circular dependencies are not working correctly.
> {code:java|title=Example Reproducer}
> final RuntimeException r1 = new RuntimeException("Exception 1");
> final RuntimeException r2 = new RuntimeException("Exception 2", r1);
> final RuntimeException r3 = new RuntimeException("Exception 3", r2);
> final RuntimeException cause = new RuntimeException("This is the cause", r1);
> cause.addSuppressed(r2);
> cause.addSuppressed(r3);
> Logger.getLogger(Main.class).error("Log message", cause);
> {code}
> {code:title=Output from JBoss Log Manager}
> 13:03:53,684 ERROR [com.jamezp.test.Main] Log message: java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> Caused by: java.lang.RuntimeException: Exception 1
> 	at com.jamezp.test.Main.main(Main.java:161)
> 	... 5 more
> {code}
> {code:title=Output from Throwable.printStackTrace()}
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}
> {code:title=Output from JUL}
> Jan 26, 2017 1:06:29 PM com.jamezp.test.Main main
> ERROR: Log message
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 17:31:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 17:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.36582.1487284260067@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8148:
-----------------------------------
    Description: 
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.

  was:
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}

Server log ERROR which explains why the JNDI lookup fails:

{code}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "app2.ear")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "app2.ear" was rolled back with the following failure message: 
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
{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.



> 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  Thu Feb 16 17:33:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 17:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.36584.1487284380051@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365084#comment-13365084 ] 

Brian Stansberry commented on WFLY-8148:
----------------------------------------

My original post of this JIRA's description said the following was the cause of failure but that is incorrect:

{code}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "app2.ear")]) - failure description: {
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
&amp#27;[0m&amp#27;[31m10:41:54,799 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "app2.ear" was rolled back with the following failure message: 
{
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"app1.ear\".deploymentCompleteService"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.deployment.subunit.\"app2.ear\".\"hello.jar\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]",
        "jboss.deployment.unit.\"app2.ear\".PARSE is missing [jboss.deployment.unit.\"app1.ear\".deploymentCompleteService]"
    ]
}
{code}

That logging is expected and correct. The test deliberately deploys and app2.ear that depends on app1.ear, but before app1.ear is deployed. So that is expected to fail and ^^^ is just the logging associated with that failure.

> 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  Thu Feb 16 18:20:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 16 Feb 2017 18:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-146) Suppressed exception format
 is not correct
In-Reply-To: <JIRA.12673311.1485465008000@Atlassian.JIRA>
References: <JIRA.12673311.1485465008000@Atlassian.JIRA>
	<JIRA.12673311.1485465008000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673311.1485465008000.36672.1487287200135@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-146:
------------------------------------

      Assignee: James Perkins
    Resolution: Done


> Suppressed exception format is not correct
> ------------------------------------------
>
>                 Key: LOGMGR-146
>                 URL: https://issues.jboss.org/browse/LOGMGR-146
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.0.5.Final, 2.1.0.Beta1
>
>
> The suppressed exception format is not correct when multiple exceptions are suppressed. Too many causes are printed likely because the circular dependencies are not working correctly.
> {code:java|title=Example Reproducer}
> final RuntimeException r1 = new RuntimeException("Exception 1");
> final RuntimeException r2 = new RuntimeException("Exception 2", r1);
> final RuntimeException r3 = new RuntimeException("Exception 3", r2);
> final RuntimeException cause = new RuntimeException("This is the cause", r1);
> cause.addSuppressed(r2);
> cause.addSuppressed(r3);
> Logger.getLogger(Main.class).error("Log message", cause);
> {code}
> {code:title=Output from JBoss Log Manager}
> 13:03:53,684 ERROR [com.jamezp.test.Main] Log message: java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> Caused by: java.lang.RuntimeException: Exception 1
> 	at com.jamezp.test.Main.main(Main.java:161)
> 	... 5 more
> {code}
> {code:title=Output from Throwable.printStackTrace()}
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}
> {code:title=Output from JUL}
> Jan 26, 2017 1:06:29 PM com.jamezp.test.Main main
> ERROR: Log message
> java.lang.RuntimeException: This is the cause
> 	at com.jamezp.test.Main.main(Main.java:165)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> 	Suppressed: java.lang.RuntimeException: Exception 2
> 		at com.jamezp.test.Main.main(Main.java:162)
> 		... 5 more
> 	Caused by: java.lang.RuntimeException: Exception 1
> 		at com.jamezp.test.Main.main(Main.java:161)
> 		... 5 more
> 	Suppressed: java.lang.RuntimeException: Exception 3
> 		at com.jamezp.test.Main.main(Main.java:163)
> 		... 5 more
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 2]
> 	[CIRCULAR REFERENCE:java.lang.RuntimeException: Exception 1]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 18:24:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 16 Feb 2017 18:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-144) Allow the # symbol to be
 used for expressions in a PatternFormatter
In-Reply-To: <JIRA.12661072.1478899658000@Atlassian.JIRA>
References: <JIRA.12661072.1478899658000@Atlassian.JIRA>
	<JIRA.12661072.1478899658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661072.1478899658000.36678.1487287440079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-144:
---------------------------------
    Fix Version/s: 2.1.0.Beta1


> Allow the # symbol to be used for expressions in a PatternFormatter
> -------------------------------------------------------------------
>
>                 Key: LOGMGR-144
>                 URL: https://issues.jboss.org/browse/LOGMGR-144
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.1.0.Beta1
>
>
> Currently in the format pattern when you want to define an expression the format pattern is {code}
> %${system.property.key:default-value}
> {code}
> This can cause problems other applications that parse the same type of expression format like WildFly. Adding an option like the following will allow a workaround for this issue.
> {code}
> %#{system.property.key:default:value}
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 18:25:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 18:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8149)
 InterDeploymentDependenciesEarTestCase does not remove its deployments
In-Reply-To: <JIRA.12677417.1487287453000@Atlassian.JIRA>
References: <JIRA.12677417.1487287453000@Atlassian.JIRA>
	<JIRA.12677417.1487287453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677417.1487287453000.36685.1487287500330@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-8899 to WFLY-8149:
-----------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8149  (was: JBEAP-8899)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Test Suite
                     (was: Test Suite)


> InterDeploymentDependenciesEarTestCase does not remove its deployments
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8149
>                 URL: https://issues.jboss.org/browse/WFLY-8149
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> Test adds deployments to the server and then leaves them behind. Tests should clean up after themselves.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 18:35:00 2017
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 16 Feb 2017 18:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2305) Upgrade JBoss Log Manager
 from 2.0.4.Final to 2.0.5.Final
In-Reply-To: <JIRA.12677418.1487288044000@Atlassian.JIRA>
References: <JIRA.12677418.1487288044000@Atlassian.JIRA>
	<JIRA.12677418.1487288044458@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677418.1487288044000.36708.1487288100095@Atlassian.JIRA>

James Perkins created WFCORE-2305:
-------------------------------------

             Summary: Upgrade JBoss Log Manager from 2.0.4.Final to 2.0.5.Final
                 Key: WFCORE-2305
                 URL: https://issues.jboss.org/browse/WFCORE-2305
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor


Only two fixes are in this release, LOGMGR-141 and LOGMGR-146. The later, LOGMGR-146, may be important to render stack traces correctly.

https://github.com/jboss-logging/jboss-logmanager/compare/2.0.4.Final...2.0.5.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 20:55:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 20:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8149)
 InterDeploymentDependenciesEarTestCase does not remove its deployments
In-Reply-To: <JIRA.12677417.1487287453000@Atlassian.JIRA>
References: <JIRA.12677417.1487287453000@Atlassian.JIRA>
	<JIRA.12677417.1487287453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677417.1487287453000.36914.1487296500072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8149:
-----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9670  (was: https://github.com/jbossas/jboss-eap7/pull/1086)


> InterDeploymentDependenciesEarTestCase does not remove its deployments
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8149
>                 URL: https://issues.jboss.org/browse/WFLY-8149
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 11.0.0.Alpha1
>
>
> Test adds deployments to the server and then leaves them behind. Tests should clean up after themselves.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 21:00:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 16 Feb 2017 21:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.36930.1487296800100@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365119#comment-13365119 ] 

Brian Stansberry commented on WFLY-8148:
----------------------------------------

Before anyone spends time on this, I recommend checking if this test stills fails after my WFLY-8149 fix. I don't have a good reason to think it won't, but TBH I don't understand why the changes I made to the original contributor PR for that issue had the effect it did.

> 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  Thu Feb 16 21:15:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 16 Feb 2017 21:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8150) The undertow attributes:
 "processing-time" and "max-processing-time" do not have "unit" defined
In-Reply-To: <JIRA.12677423.1487297638000@Atlassian.JIRA>
References: <JIRA.12677423.1487297638000@Atlassian.JIRA>
	<JIRA.12677423.1487297638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677423.1487297638000.36942.1487297700167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-8902 to WFLY-8150:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8150  (was: JBEAP-8902)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s:     (was: 7.0.4.GA)


> The undertow attributes: "processing-time" and "max-processing-time" do not have "unit" defined
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8150
>                 URL: https://issues.jboss.org/browse/WFLY-8150
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> The undertow attributes: "processing-time" and "max-processing-time" do not have "unit" defined. For instance, if you execute:
> /subsystem=undertow/server=default-server/http-listener=default:read-resource-description
> this will return:
> ...
> "max-processing-time" =>
> { "type" => LONG, "description" => "The maximum processing time taken by a request on this listener", "expressions-allowed" => false, "nillable" => false, "access-type" => "metric", "storage" => "runtime" }
> ,
> "no-request-timeout" =>
> { "type" => INT, "description" => "The length of time in milliseconds that the connection can be idle before it is closed by the container, defaults to 60000 (one minute)", "expressions-allowed" => true, "nillable" => true, "default" => 60000, "unit" => "MILLISECONDS", "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }
> ,
> "processing-time" => {
> "type" => LONG,
> "description" => "The total processing time of all requests handed by this listener",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> ...
> According to the code:
> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/ConnectorStatisticsImpl.java#L63
> attributes "processing-time" and "max-processing-time" should be shown as nano seconds.
> I have just realised that only few attributes have "unit" defined - like "no-request-timeout" while the most of them is without it.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 22:46:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 16 Feb 2017 22:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-967) Impossible to authorize as a
 non-name Principal
In-Reply-To: <JIRA.12677432.1487303118000@Atlassian.JIRA>
References: <JIRA.12677432.1487303118000@Atlassian.JIRA>
	<JIRA.12677432.1487303118627@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677432.1487303118000.36959.1487303160101@Atlassian.JIRA>

David Lloyd created ELY-967:
-------------------------------

             Summary: Impossible to authorize as a non-name Principal
                 Key: ELY-967
                 URL: https://issues.jboss.org/browse/ELY-967
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Server, API / SPI
            Reporter: David Lloyd
            Priority: Minor


There are no methods on SecurityIdentity to create a run-as authorized user with a Principal, only a String name.  There is no authorize(Principal) variant on ServerAuthenticationContext.

These should be added to support realms which do not use plain text names to identify users.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 16 22:47:00 2017
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 16 Feb 2017 22:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-968) SI.createRunAsIdentity ignores
 authorize flag
In-Reply-To: <JIRA.12677433.1487303185000@Atlassian.JIRA>
References: <JIRA.12677433.1487303185000@Atlassian.JIRA>
	<JIRA.12677433.1487303185212@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677433.1487303185000.36962.1487303220124@Atlassian.JIRA>

David Lloyd created ELY-968:
-------------------------------

             Summary: SI.createRunAsIdentity ignores authorize flag
                 Key: ELY-968
                 URL: https://issues.jboss.org/browse/ELY-968
             Project: WildFly Elytron
          Issue Type: Bug
          Components: API / SPI, Authentication Server
            Reporter: David Lloyd
            Assignee: David Lloyd


The parameter is ignored, and false is always used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 01:09:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 17 Feb 2017 01:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8151) Unable to create custom
 credentail security factory
In-Reply-To: <JIRA.12677441.1487311687000@Atlassian.JIRA>
References: <JIRA.12677441.1487311687000@Atlassian.JIRA>
	<JIRA.12677441.1487311687595@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677441.1487311687000.37122.1487311740531@Atlassian.JIRA>

Martin Choma created WFLY-8151:
----------------------------------

             Summary: Unable to create custom credentail security factory
                 Key: WFLY-8151
                 URL: https://issues.jboss.org/browse/WFLY-8151
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            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<T> implements CredentialSecurityFactory, Configurable {

    @Override
    public Credential create() throws GeneralSecurityException {
        return null;
    }

    @Override
    public void initialize(Map<String, String> 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 Feb 17 01:33:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 17 Feb 2017 01:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8152) Elytron,
 unable to create custom principal transformer
In-Reply-To: <JIRA.12677443.1487313136000@Atlassian.JIRA>
References: <JIRA.12677443.1487313136000@Atlassian.JIRA>
	<JIRA.12677443.1487313136830@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677443.1487313136000.37218.1487313180414@Atlassian.JIRA>

Martin Choma created WFLY-8152:
----------------------------------

             Summary: Elytron, unable to create custom principal transformer
                 Key: WFLY-8152
                 URL: https://issues.jboss.org/browse/WFLY-8152
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            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<String, String> 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 Feb 17 01:42:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 17 Feb 2017 01:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8153) Elytron insufficiently covers
 scenarios with more user storages - Multiple Realm Aggregation
In-Reply-To: <JIRA.12677446.1487313698000@Atlassian.JIRA>
References: <JIRA.12677446.1487313698000@Atlassian.JIRA>
	<JIRA.12677446.1487313698645@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677446.1487313698000.37277.1487313720872@Atlassian.JIRA>

Ondrej Lukas created WFLY-8153:
----------------------------------

             Summary: Elytron insufficiently covers scenarios with more user storages - Multiple Realm Aggregation
                 Key: WFLY-8153
                 URL: https://issues.jboss.org/browse/WFLY-8153
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


This issue is created on demand of developers to split original JBEAP-8734 into two issues. See JBEAP-8734 for more details.

Request blocker since this issue is very common scenario which can directly affects customers and migration to Elytron. Scenarios are mentioned by GSS in comment [1]. If you have some questions about this scenarios, please ask GSS to provide more details.

[1] https://issues.jboss.org/browse/JBEAP-8734?focusedCommentId=13362843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13362843



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 01:43:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Fri, 17 Feb 2017 01:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8154) Elytron insufficiently covers
 scenarios with more user storages - Realm Failover
In-Reply-To: <JIRA.12677447.1487313756000@Atlassian.JIRA>
References: <JIRA.12677447.1487313756000@Atlassian.JIRA>
	<JIRA.12677447.1487313756036@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677447.1487313756000.37287.1487313780324@Atlassian.JIRA>

Ondrej Lukas created WFLY-8154:
----------------------------------

             Summary: Elytron insufficiently covers scenarios with more user storages - Realm Failover
                 Key: WFLY-8154
                 URL: https://issues.jboss.org/browse/WFLY-8154
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Blocker


This issue is created on demand of developers to split original JBEAP-8734 into two issues. See JBEAP-8734 for more details.

Request blocker since this issue is very common scenario which can directly affects customers and migration to Elytron. Scenarios are mentioned by GSS in comment [1]. If you have some questions about this scenarios, please ask GSS to provide more details.

[1] https://issues.jboss.org/browse/JBEAP-8734?focusedCommentId=13362843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13362843



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 01:49:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 17 Feb 2017 01:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8155) Cover Elytron credential
 store with tests in AS TS
In-Reply-To: <JIRA.12677449.1487314084000@Atlassian.JIRA>
References: <JIRA.12677449.1487314084000@Atlassian.JIRA>
	<JIRA.12677449.1487314084936@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677449.1487314084000.37325.1487314140060@Atlassian.JIRA>

Josef Cacek created WFLY-8155:
---------------------------------

             Summary: Cover Elytron credential store with tests in AS TS
                 Key: WFLY-8155
                 URL: https://issues.jboss.org/browse/WFLY-8155
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Josef Cacek


Add Elytron credential store tests to AS TS.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 01:57:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 17 Feb 2017 01:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8155) Cover Elytron credential
 store with tests in AS TS
In-Reply-To: <JIRA.12677449.1487314085000@Atlassian.JIRA>
References: <JIRA.12677449.1487314085000@Atlassian.JIRA>
	<JIRA.12677449.1487314085000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677449.1487314085000.37369.1487314620048@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-8155:
---------------------------------

    Assignee: Josef Cacek


> Cover Elytron credential store with tests in AS TS
> --------------------------------------------------
>
>                 Key: WFLY-8155
>                 URL: https://issues.jboss.org/browse/WFLY-8155
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Add Elytron credential store tests to AS TS.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 02:35:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 17 Feb 2017 02:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6636) WELD-001408: Unsatisfied
 dependencies on hot deploy of app using module-alias as dependency
In-Reply-To: <JIRA.12627319.1463846078000@Atlassian.JIRA>
References: <JIRA.12627319.1463846078000@Atlassian.JIRA>
	<JIRA.12627319.1463846078000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12627319.1463846078000.37528.1487316900173@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365159#comment-13365159 ] 

RH Bugzilla Integration commented on WFLY-6636:
-----------------------------------------------

Matej Novotny <manovotn at redhat.com> changed the Status of [bug 1338093|https://bugzilla.redhat.com/show_bug.cgi?id=1338093] from ON_QA to VERIFIED

> WELD-001408: Unsatisfied dependencies on hot deploy of app using module-alias as dependency
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6636
>                 URL: https://issues.jboss.org/browse/WFLY-6636
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Tomas Hofman
>         Attachments: test.ear
>
>
> If a sub deployment uses another sub deployment's module-alias as a dependency, it will deploy successfully, but if hot deployed, it will fail with the error below.  Attached reproducer.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
>     <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>     <sub-deployment name="ejb1.jar">
>         <module-alias name="deployment.ejb1"/>
>     </sub-deployment>
>     <sub-deployment name="ejb2.jar">
>         <dependencies>
> <!-- works
>             <module name="deployment.test.ear.ejb1.jar" slot="main"/>
> -->
> <!-- fails with  WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default on redeploy / hot deploy -->
>             <module name="deployment.ejb1" slot="main"/>
>         </dependencies>
>     </sub-deployment>
> </jboss-deployment-structure>
> {code}
> {code}
> 10:43:42,140 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."test.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.ear".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: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
>   at test.TestEJB2.test1(TestEJB2.java:0)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> 	at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> 	at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> 	at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> 	at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> 	at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> 	at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> 	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)
> 10:43:42,144 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"test.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test.ear\".WeldStartService: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type TestEJB1 with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private test.TestEJB2.test1
>   at test.TestEJB2.test1(TestEJB2.java:0)
> "}}
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 03:21:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Fri, 17 Feb 2017 03:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1706) Build process: publish
 artifact to Nexus via ant+ivy
In-Reply-To: <JIRA.12501699.1380264757000@Atlassian.JIRA>
References: <JIRA.12501699.1380264757000@Atlassian.JIRA>
	<JIRA.12501699.1380264757000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501699.1380264757000.37710.1487319660335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365175#comment-13365175 ] 

Bela Ban commented on JGRP-1706:
--------------------------------

http://central.sonatype.org/pages/apache-ant.html

> Build process: publish artifact to Nexus via ant+ivy
> ----------------------------------------------------
>
>                 Key: JGRP-1706
>                 URL: https://issues.jboss.org/browse/JGRP-1706
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Optional
>             Fix For: 4.1
>
>
> Add publish and publish-local tasks to build.xml to publish the artifacts (JAR, soirce-JAR and readme) to Nexus or the local repo.
> Link: http://books.sonatype.com/nexus-book/reference/staging-deployment.html#staging-ant



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 03:43:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Fri, 17 Feb 2017 03:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8156) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677462.1487320943000@Atlassian.JIRA>
References: <JIRA.12677462.1487320943000@Atlassian.JIRA>
	<JIRA.12677462.1487320943783@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677462.1487320943000.37843.1487320980139@Atlassian.JIRA>

Martin Simka created WFLY-8156:
----------------------------------

             Summary: CachedConnectionManager add operation excepts no parameters anymore
                 Key: WFLY-8156
                 URL: https://issues.jboss.org/browse/WFLY-8156
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, JCA
    Affects Versions: 11.0.0.Alpha1
            Reporter: Martin Simka
            Assignee: Ingo Weiss
            Priority: Critical


Fix for WFLY-2640 broke :add operation for cached-connection-manager
scipts that do

{noformat}
/profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
{noformat}
{noformat}
/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
{noformat}
now fail with
{{Operation 'add' does not expect any property.}}

This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 04:13:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 17 Feb 2017 04:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178533000@Atlassian.JIRA>
References: <JIRA.12677036.1487178533000@Atlassian.JIRA>
	<JIRA.12677036.1487178533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178533000.38162.1487322780532@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365216#comment-13365216 ] 

Mario Fusco commented on DROOLS-1444:
-------------------------------------

Implementing AutoCloseable is only useful if you're planning to use the AutoCloseable resource in a try-with-resources block, but to be honest I don't think it will be common at all to use a KieSession in that way. Do you have a use case where you may need (or want) to do that? If so can you please paste the code snippet where you tried to do this, so I could have a better idea regarding the possible implications?

> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
>                 Key: DROOLS-1444
>                 URL: https://issues.jboss.org/browse/DROOLS-1444
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: tech meshter
>            Assignee: Mario Fusco
>            Priority: Minor
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 04:40:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 17 Feb 2017 04:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2306) CLI --timeout option has
 not accurate description
In-Reply-To: <JIRA.12677484.1487324393000@Atlassian.JIRA>
References: <JIRA.12677484.1487324393000@Atlassian.JIRA>
	<JIRA.12677484.1487324393633@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677484.1487324393000.38488.1487324400708@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2306:
--------------------------------------------

             Summary: CLI --timeout option has not accurate description
                 Key: WFCORE-2306
                 URL: https://issues.jboss.org/browse/WFCORE-2306
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


There is no mention of "connection" although this option addresses connection.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 04:42:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 17 Feb 2017 04:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8142) Review & update
	ejb-multi-server documents
In-Reply-To: <JIRA.12677282.1487257410000@Atlassian.JIRA>
References: <JIRA.12677282.1487257410000@Atlassian.JIRA>
	<JIRA.12677282.1487257410000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677282.1487257410000.38521.1487324520926@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365246#comment-13365246 ] 

Tomaz Cerar commented on WFLY-8142:
-----------------------------------

For "both" as after sync is done they will be the same.

This is here just for tracking now, as it needs to be done before .GA
as currently this whole QS is a big mess and doesn't work at all so needs to be fixed first.

> Review & update ejb-multi-server documents
> ------------------------------------------
>
>                 Key: WFLY-8142
>                 URL: https://issues.jboss.org/browse/WFLY-8142
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Quickstarts
>            Reporter: Tomaz Cerar
>            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  Fri Feb 17 05:12:02 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 17 Feb 2017 05:12:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1442) ServiceRegistry references
 non existent classes
In-Reply-To: <JIRA.12676900.1487153704000@Atlassian.JIRA>
References: <JIRA.12676900.1487153704000@Atlassian.JIRA>
	<JIRA.12676900.1487153704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676900.1487153704000.38907.1487326322233@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1442.
---------------------------------
    Fix Version/s: 7.0.0.CR1
       Resolution: Done


Fixed by https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/a988de4491074f48df16c92147d2072b70a13431 and https://github.com/droolsjbpm/drools/commit/df070474e8fbeef838f9be303d5badd57386b874

> ServiceRegistry references non existent classes
> -----------------------------------------------
>
>                 Key: DROOLS-1442
>                 URL: https://issues.jboss.org/browse/DROOLS-1442
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Anton Giertli
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.CR1
>
>
> This code
> {code:java}
>         SystemEventListener listener =  SystemEventListenerFactory.getSystemEventListener();
> {code}
> Fails with:
> Caused by: java.lang.ClassNotFoundException: org.drools.core.impl.SystemEventListenerServiceImpl
> Because ServiceRegistryImpl 
> https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/master/kie-internal/src/main/java/org/kie/internal/utils/ServiceRegistryImpl.java#L189
> references class SystemEventListenerServiceImpl which does not exist anymore in drools-core.
> The interface SystemEventListenerService still exists in kie-internal but there is no implementation whatsoever in drools.
> First impression is that both SystemEventListenerService + SystemEventListenerServiceImpl are "dead" code and should probably be removed.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 05:13:02 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 17 Feb 2017 05:13:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8157) Synchronize XSD and DMR
 description of credential-store attributes
In-Reply-To: <JIRA.12677496.1487326381000@Atlassian.JIRA>
References: <JIRA.12677496.1487326381000@Atlassian.JIRA>
	<JIRA.12677496.1487326381821@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677496.1487326381000.38977.1487326382522@Atlassian.JIRA>

Martin Choma created WFLY-8157:
----------------------------------

             Summary: Synchronize XSD and DMR description of credential-store attributes
                 Key: WFLY-8157
                 URL: https://issues.jboss.org/browse/WFLY-8157
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


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 use this description in both XSD and DMR:
* The credential store type, e.g. KeyStoreCredentialStore
** There is mentioned wrong KeyStorePasswordStore




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 05:14:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 17 Feb 2017 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8157) Synchronize XSD and DMR
 description of credential-store attributes
In-Reply-To: <JIRA.12677496.1487326382000@Atlassian.JIRA>
References: <JIRA.12677496.1487326382000@Atlassian.JIRA>
	<JIRA.12677496.1487326382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677496.1487326382000.38993.1487326440977@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8157:
-------------------------------
    Description: 
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}
        <xs:attribute name="type" type="xs:string" use="optional">
            <xs:annotation>
                <xs:documentation>
                    The credential store type, e.g. KeyStorePasswordStore.
                </xs:documentation>
            </xs:annotation>
        </xs:attribute>
{code}


  was:
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 use this description in both XSD and DMR:
* The credential store type, e.g. KeyStoreCredentialStore
** There is mentioned wrong KeyStorePasswordStore




> Synchronize XSD and DMR description of credential-store attributes
> ------------------------------------------------------------------
>
>                 Key: WFLY-8157
>                 URL: https://issues.jboss.org/browse/WFLY-8157
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              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}
>         <xs:attribute name="type" type="xs:string" use="optional">
>             <xs:annotation>
>                 <xs:documentation>
>                     The credential store type, e.g. KeyStorePasswordStore.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 05:14:01 2017
From: issues at jboss.org (=?UTF-8?Q?Martin_=C5=A0vehla_=28JIRA=29?=)
Date: Fri, 17 Feb 2017 05:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2307) Rename
 wildfly-elytron-tool.jar to elytron-tool.jar to be consistent with other
 jars in bin directory
In-Reply-To: <JIRA.12677495.1487326320000@Atlassian.JIRA>
References: <JIRA.12677495.1487326320000@Atlassian.JIRA>
	<JIRA.12677495.1487326320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677495.1487326320000.39001.1487326441307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin ?vehla moved JBEAP-8921 to WFCORE-2307:
----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2307  (was: JBEAP-8921)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR12)


> Rename wildfly-elytron-tool.jar to elytron-tool.jar to be consistent with other jars in bin directory
> -----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2307
>                 URL: https://issues.jboss.org/browse/WFCORE-2307
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin ?vehla
>            Assignee: Peter Skopek
>
> We should consider dropping wildfly prefix, as we're generally trying to avoid having that
> See for example https://issues.jboss.org/browse/WFCORE-1302 for similar issue (the jira si related to renaming wildfly-launcher.jar to launcher.jar).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 17 05:29:00 2017
From: issues at jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 17 Feb 2017 05:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.39237.1487327340440@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365302#comment-13365302 ] 

Alexey Loubyansky commented on WFLY-8141:
-----------------------------------------

The workaround will be to disable operation request validation in the cli, i.e. validate-option-requests in jboss-cli.xml. But the issue has to be addressed in the JCA.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 05:36:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 17 Feb 2017 05:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1443) Improve effect of caching
 in ChainedProperties.
In-Reply-To: <JIRA.12676988.1487168226000@Atlassian.JIRA>
References: <JIRA.12676988.1487168226000@Atlassian.JIRA>
	<JIRA.12676988.1487168226000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676988.1487168226000.39304.1487327760135@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365312#comment-13365312 ] 

Mario Fusco commented on DROOLS-1443:
-------------------------------------

What you're suggesting sounds interesting but it is not entirely clear to me. In particular I don't understand how you could implement meaningful hashcode and equals methods on a ClassLoader. If you already implemented this could you maybe send a pull request with what you did or at least paste it somewhere? Thank you.

> Improve effect of caching in ChainedProperties.  
> -------------------------------------------------
>
>                 Key: DROOLS-1443
>                 URL: https://issues.jboss.org/browse/DROOLS-1443
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Hans Lund
>            Assignee: Mario Fusco
>            Priority: Minor
>
> The ChainedProperties utility has a caching setting that will cache the classpath discovery of property resource - but not the parsing of these resources.
> This utility is a hot spot for the initialization of runtime environments - caching the parsed properties instead of the resource url will improve runtime performance.
> Changing the caching strategy will make hot changes to classpath property resources impossible. File based property files could be made safe cacheable by investigating file metadata and only read if changed.     



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 06:20:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 17 Feb 2017 06:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.40352.1487330400978@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman reassigned ELY-880:
--------------------------------

    Assignee: Tomas Hofman


> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 06:53:00 2017
From: issues at jboss.org (Markus Markus (JIRA))
Date: Fri, 17 Feb 2017 06:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8158) JSP source code leak when
 space and periods added at the end of the URL
In-Reply-To: <JIRA.12677510.1487332335000@Atlassian.JIRA>
References: <JIRA.12677510.1487332335000@Atlassian.JIRA>
	<JIRA.12677510.1487332335237@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677510.1487332335000.40761.1487332380324@Atlassian.JIRA>

Markus Markus created WFLY-8158:
-----------------------------------

             Summary: JSP source code leak when space and periods added at the end of the URL
                 Key: WFLY-8158
                 URL: https://issues.jboss.org/browse/WFLY-8158
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.2.0.Final
         Environment: WildFly executing on Windows
            Reporter: Markus Markus
            Assignee: Stuart Douglas
            Priority: Blocker


All of the following requests will return the jsp file content untransformed, meaning that the actual content of the jsp-file is returned to the browser.

{code}
http://localhost:8080/application/HostPage.jsp%2E
http://localhost:8080/application/HostPage.jsp%2E%2E
http://localhost:8080/application/HostPage.jsp%20%2E
http://localhost:8080/application/HostPage.jsp%20%2E%2E
{code}

The problem with periods has perhaps to do with windows removing/accepting trailing periods in file names: [here|http://stackoverflow.com/questions/17746494/why-is-directory-name-which-contains-dots-in-the-end-is-treated-as-a-directory], [and here|http://stackoverflow.com/questions/11681207/how-to-create-a-filename-with-a-trailing-period-in-windows/16203594#16203594] because {{io.undertow.server.handlers.resource.FileResourceManager.getResource()}} delegates to {{java.io.File}} to test whether a file path is valid or not, and {{java.io.File}} does presumably delegate to Windows.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 07:15:00 2017
From: issues at jboss.org (Markus Markus (JIRA))
Date: Fri, 17 Feb 2017 07:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8158) JSP source code leak when
 space and periods added at the end of the URL
In-Reply-To: <JIRA.12677510.1487332335000@Atlassian.JIRA>
References: <JIRA.12677510.1487332335000@Atlassian.JIRA>
	<JIRA.12677510.1487332335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677510.1487332335000.40845.1487333700710@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365368#comment-13365368 ] 

Markus Markus commented on WFLY-8158:
-------------------------------------

Note: we have +not+ tried to find out if the error is present on any other WildFly version (because we do not use any other WildFly version for the particular use case where this bug is of importance to us)

> JSP source code leak when space and periods added at the end of the URL
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8158
>                 URL: https://issues.jboss.org/browse/WFLY-8158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: WildFly executing on Windows
>            Reporter: Markus Markus
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> All of the following requests will return the jsp file content untransformed, meaning that the actual content of the jsp-file is returned to the browser.
> {code}
> http://localhost:8080/application/HostPage.jsp%2E
> http://localhost:8080/application/HostPage.jsp%2E%2E
> http://localhost:8080/application/HostPage.jsp%20%2E
> http://localhost:8080/application/HostPage.jsp%20%2E%2E
> {code}
> The problem with periods has perhaps to do with windows removing/accepting trailing periods in file names: [here|http://stackoverflow.com/questions/17746494/why-is-directory-name-which-contains-dots-in-the-end-is-treated-as-a-directory], [and here|http://stackoverflow.com/questions/11681207/how-to-create-a-filename-with-a-trailing-period-in-windows/16203594#16203594] because {{io.undertow.server.handlers.resource.FileResourceManager.getResource()}} delegates to {{java.io.File}} to test whether a file path is valid or not, and {{java.io.File}} does presumably delegate to Windows.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 07:18:00 2017
From: issues at jboss.org (Sande Gilda (JIRA))
Date: Fri, 17 Feb 2017 07:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8142) Review & update
	ejb-multi-server documents
In-Reply-To: <JIRA.12677282.1487257410000@Atlassian.JIRA>
References: <JIRA.12677282.1487257410000@Atlassian.JIRA>
	<JIRA.12677282.1487257410000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677282.1487257410000.40878.1487333880259@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365371#comment-13365371 ] 

Sande Gilda commented on WFLY-8142:
-----------------------------------

[~ctomc]: Normally all product quickstart bugs need a JBEAP project issue for tracking purposes. Should I move this one to JBEAP?

> Review & update ejb-multi-server documents
> ------------------------------------------
>
>                 Key: WFLY-8142
>                 URL: https://issues.jboss.org/browse/WFLY-8142
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Quickstarts
>            Reporter: Tomaz Cerar
>            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  Fri Feb 17 07:56:00 2017
From: issues at jboss.org (kenji uno (JIRA))
Date: Fri, 17 Feb 2017 07:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-704) Java scriptTask compilation
 error reports invalid line
In-Reply-To: <JIRA.12562321.1422972754000@Atlassian.JIRA>
References: <JIRA.12562321.1422972754000@Atlassian.JIRA>
	<JIRA.12562321.1422972754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562321.1422972754000.41200.1487336160122@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365408#comment-13365408 ] 

kenji uno commented on DROOLS-704:
----------------------------------

[-Ddrools.dump.dir|http://blog.athico.com/2008/02/looking-under-drools-skirt.html] may be helpful to trace Java scriptTask compilation error.

Like: _mvn -Ddrools.dump.dir="C:\folder" kie:build_

> Java scriptTask compilation error reports invalid line
> ------------------------------------------------------
>
>                 Key: DROOLS-704
>                 URL: https://issues.jboss.org/browse/DROOLS-704
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.1.0.Final
>         Environment: Windows 7 x64,
> jdk1.6.0_45 x64
> jbpm 6.1.0.Final
>            Reporter: ???????? ?????????
>            Assignee: Petr ?irok?
>            Priority: Minor
>
> In case of a compilation error inside the scriptTask java code, the line and the column reported inside the org.drools.compiler.kie.builder.impl.MessageImpl are incorrect.
> The MessageImpl.getPath() should also return a path with the node id that contains the compilation error.
> To reproduce:
> {code:java}
> KieHelper kieHelper = new KieHelper();
> kieHelper.addResource(ResourceFactory.newClassPathResource("sample-jbpm6.bpmn"));
> Results res =  kieHelper.verify();
> for (Message msg : res.getMessages()) {
>      System.out.println("Error: " + msg);
> }
> if (res.hasMessages(Message.Level.ERROR)) {
>      throw new IllegalStateException("Could not verify the workflow");
> }
> {code}
> {noformat}
> Error: class org.drools.compiler.kie.builder.impl.MessageImpl
> [main] ERROR org.drools.compiler.kie.builder.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Process Compilation error : Process org.jbpm.Hello World(com.sample.bpmn.hello)
> 	org/jbpm/Process_org$u46$jbpm$u46$Hello_World265679914.java (9:416) : Syntax error on token "halskdjfh", delete this token
> Exception in thread "main" java.lang.IllegalStateException: Could not verify the workflow
> 	at Main.main(Main.java:26)
> 	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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Process finished with exit code 1
> {noformat}
> I've tested with both with "ECLIPSE" and "NATIVE" as values of the "drools.dialect.java.compiler".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 17 07:58:00 2017
From: issues at jboss.org (Hans Lund (JIRA))
Date: Fri, 17 Feb 2017 07:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1443) Improve effect of caching
 in ChainedProperties.
In-Reply-To: <JIRA.12676988.1487168226000@Atlassian.JIRA>
References: <JIRA.12676988.1487168226000@Atlassian.JIRA>
	<JIRA.12676988.1487168226000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676988.1487168226000.41205.1487336280085@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365410#comment-13365410 ] 

Hans Lund commented on DROOLS-1443:
-----------------------------------

[~mfusco] added the PR. The hashcode on ProjectClassloader is very simple - it delegates to hashcode of its wrapped classloaders making the hashcode for a projcectclassloader equal for all instances wrapping the exact same instances for underlying loaders - which in here is just whats needed ;-)

> Improve effect of caching in ChainedProperties.  
> -------------------------------------------------
>
>                 Key: DROOLS-1443
>                 URL: https://issues.jboss.org/browse/DROOLS-1443
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Hans Lund
>            Assignee: Mario Fusco
>            Priority: Minor
>
> The ChainedProperties utility has a caching setting that will cache the classpath discovery of property resource - but not the parsing of these resources.
> This utility is a hot spot for the initialization of runtime environments - caching the parsed properties instead of the resource url will improve runtime performance.
> Changing the caching strategy will make hot changes to classpath property resources impossible. File based property files could be made safe cacheable by investigating file metadata and only read if changed.     



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 08:09:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 17 Feb 2017 08:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8159) Elytron profile in
 integration module of the AS TS fails for the module itself
In-Reply-To: <JIRA.12677523.1487336890000@Atlassian.JIRA>
References: <JIRA.12677523.1487336890000@Atlassian.JIRA>
	<JIRA.12677523.1487336890191@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677523.1487336890000.41290.1487336940305@Atlassian.JIRA>

Josef Cacek created WFLY-8159:
---------------------------------

             Summary: Elytron profile in integration module of the AS TS fails for the module itself
                 Key: WFLY-8159
                 URL: https://issues.jboss.org/browse/WFLY-8159
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Josef Cacek


The elytron profile in {{testsuite/integration}} should only be activated in child modules. There should also be a possibility to provide custom CLI script (as for instance the web module uses very slim server configuration.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 08:10:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 17 Feb 2017 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.41302.1487337000192@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365416#comment-13365416 ] 

Darran Lofthouse commented on ELY-880:
--------------------------------------

[~thofman] FYI if you are going to take this issue this issue probably will need to go beyond just supporting it being set, we also need to be sure that matches for IPv6 addresses work correctly at match time especially keeping in mind that a single address can have more than one representation.



> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 08:28:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Fri, 17 Feb 2017 08:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8029) Servlet lifecycle tests fail
 with security manager
In-Reply-To: <JIRA.12674984.1486368176000@Atlassian.JIRA>
References: <JIRA.12674984.1486368176000@Atlassian.JIRA>
	<JIRA.12674984.1486368176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674984.1486368176000.41464.1487338080412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFLY-8029:
-----------------------------------

    Assignee: Ivo Studensky


> Servlet lifecycle tests fail with security manager
> --------------------------------------------------
>
>                 Key: WFLY-8029
>                 URL: https://issues.jboss.org/browse/WFLY-8029
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ivo Studensky
>
> Following tests fail when {{-Dnode0}} property is set (e.g. in QE CI runs)
> *org.jboss.as.test.integration.ee.lifecycle.servlet.FilterLifecycleCallbackInterceptionTestCase#testFilterPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=FilterLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 401c8348: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteFilter$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedFilter.stop(ManagedFilter.java:101)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 55 more
> {code}
> *org.jboss.as.test.integration.ee.lifecycle.servlet.ListenerLifecycleCallbackInterceptionTestCase#testListenerPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ListenerLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 10) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 273c588b: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteListener$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedListener.stop(ManagedListener.java:59)
> 	at io.undertow.servlet.core.ApplicationListeners.stop(ApplicationListeners.java:167)
> 	at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:254)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:636)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$4.call(DeploymentManagerImpl.java:633)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:641)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:143)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 57 more
> {code}
> *org.jboss.as.test.integration.ee.lifecycle.servlet.ServletLifecycleCallbackInterceptionTestCase#testServletPreDestroyInterception*
> # export MYTESTIP_1=192.168.1.50
> # sudo ifconfig em1:0 192.168.1.50
> # ./integration-tests.sh -DtestLogToFile=false -Dts.basic -Dtest=ServletLifecycleCallbackInterceptionTestCase -Dsecurity.manager -Dnode0=$MYTESTIP_1
> {code}
> [org.jboss.as.ee] (ServerService Thread Pool -- 28) WFLYEE0006: Failed to destroy component instance org.jboss.as.ee.component.BasicComponentInstance at 91cc90c: java.lang.RuntimeException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.war" from Service Module Loader")
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:40)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.LifecycleCallbackInterceptor.preDestroy(LifecycleCallbackInterceptor.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.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83)
> 	at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeLifecycleInterception(InterceptorMethodHandler.java:78)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:74)
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:84)
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:61)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.RemoteServlet$Proxy$_$$_WeldSubclass.lifecycle_mixin_$$_preDestroy(Unknown Source)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:67)
> 	at org.jboss.weld.interceptor.util.InterceptionUtils.executePredestroy(InterceptionUtils.java:79)
> 	at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:88)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$4.run(WeldComponentIntegrationProcessor.java:235)
> 	at org.jboss.as.weld.deployment.processors.WeldComponentIntegrationProcessor$AbstractInjectionTargetDelegatingInterceptor.processInvocation(WeldComponentIntegrationProcessor.java:293)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:359)
> 	at org.jboss.as.ee.component.ManagedReferenceReleaseInterceptor.processInvocation(ManagedReferenceReleaseInterceptor.java:56)
> 	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.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	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.BasicComponentInstance.destroy(BasicComponentInstance.java:125)
> 	at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReference.release(ComponentRegistry.java:106)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6$1.release(UndertowDeploymentInfoService.java:1412)
> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.stop(ManagedServlet.java:266)
> 	at io.undertow.servlet.core.ManagedServlet.stop(ManagedServlet.java:146)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:581)
> 	at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:576)
> 	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.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1696)
> 	at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:590)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.net.SocketPermission" "192.168.1.50:8080" "connect,resolve")" in code source "(vfs:/content/remote.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.remote.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.SecurityManager.checkConnect(SecurityManager.java:1051)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:380)
> 	at sun.net.www.http.HttpClient.openServer(HttpClient.java:510)
> 	at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:308)
> 	at sun.net.www.http.HttpClient.New(HttpClient.java:326)
> 	at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
> 	at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
> 	at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> 	at org.jboss.as.test.integration.ee.lifecycle.servlet.InfoClient.notify(InfoClient.java:38)
> 	... 56 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 08:36:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Fri, 17 Feb 2017 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.41539.1487338560930@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365441#comment-13365441 ] 

Tomas Hofman commented on ELY-880:
----------------------------------

[~dlofthouse], I'm just looking at how the matchers are working.

My thought was to convert the IPv6 addresses to canonical representation. I suppose matching by prefix of the address should be supported too - it is for IPv4.

> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 09:02:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 17 Feb 2017 09:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7408) Look into automating
 generation of README html files from .md
In-Reply-To: <JIRA.12657797.1477667334000@Atlassian.JIRA>
References: <JIRA.12657797.1477667334000@Atlassian.JIRA>
	<JIRA.12657797.1477667334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657797.1477667334000.41869.1487340120718@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365469#comment-13365469 ] 

Tomaz Cerar commented on WFLY-7408:
-----------------------------------

currently there is .md --> .html generation done that also expands variables.
to enable it you need to use -Pdocs profile when building.

table of contents is not generated yet, for that ruby script is still needed.

> Look into automating generation of README html files from .md
> -------------------------------------------------------------
>
>                 Key: WFLY-7408
>                 URL: https://issues.jboss.org/browse/WFLY-7408
>             Project: WildFly
>          Issue Type: Task
>          Components: Quickstarts
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Currently we need to manually run 
> dist/release-utils -m
> and have setup of ruby and all its gems.
> Look into possibly automating this by some maven plugin if possible.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 09:48:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 17 Feb 2017 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2306) CLI --timeout option has
 not accurate description
In-Reply-To: <JIRA.12677484.1487324394000@Atlassian.JIRA>
References: <JIRA.12677484.1487324394000@Atlassian.JIRA>
	<JIRA.12677484.1487324394000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677484.1487324394000.42320.1487342880776@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365522#comment-13365522 ] 

Jean-Francois Denise commented on WFCORE-2306:
----------------------------------------------

[~ahoffer], that is the fix for invalid timeout description.


> CLI --timeout option has not accurate description
> -------------------------------------------------
>
>                 Key: WFCORE-2306
>                 URL: https://issues.jboss.org/browse/WFCORE-2306
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> There is no mention of "connection" although this option addresses connection.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 10:30:00 2017
From: issues at jboss.org (Mahesh Reddy (JIRA))
Date: Fri, 17 Feb 2017 10:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File
	Descriptor leak
In-Reply-To: <JIRA.12677566.1487345346000@Atlassian.JIRA>
References: <JIRA.12677566.1487345346000@Atlassian.JIRA>
	<JIRA.12677566.1487345346164@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677566.1487345346000.42904.1487345400150@Atlassian.JIRA>

Mahesh Reddy created WFLY-8160:
----------------------------------

             Summary: 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: 10.1.0.Final, 9.0.2.Final, 9.0.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 <pid>, 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 Feb 17 10:34:00 2017
From: issues at jboss.org (Mahesh Reddy (JIRA))
Date: Fri, 17 Feb 2017 10:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File
	Descriptor leak
In-Reply-To: <JIRA.12677566.1487345346000@Atlassian.JIRA>
References: <JIRA.12677566.1487345346000@Atlassian.JIRA>
	<JIRA.12677566.1487345346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677566.1487345346000.42938.1487345640856@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365579#comment-13365579 ] 

Mahesh Reddy commented on WFLY-8160:
------------------------------------

New file descriptors i see created for each request. Sample as below
> java    18967 megha *921r     FIFO                0,8       0t0 1244095284 pipe
> java    18967 megha *922w     FIFO                0,8       0t0 1244095284 pipe
> java    18967 megha *923u  a_inode                0,9         0       6115 [eventpoll]

> 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 <pid>, 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 Feb 17 10:38:00 2017
From: issues at jboss.org (John Mazzitelli (JIRA))
Date: Fri, 17 Feb 2017 10:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860364@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.42981.1487345880677@Atlassian.JIRA>

John Mazzitelli created WFLY-8161:
-------------------------------------

             Summary: JDR Subsystem destroys password related system properties
                 Key: WFLY-8161
                 URL: https://issues.jboss.org/browse/WFLY-8161
             Project: WildFly
          Issue Type: Task
          Components: JDR
    Affects Versions: 10.1.0.Final, 10.0.0.Final
            Reporter: John Mazzitelli
            Assignee: Brad Maxwell


When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:

https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53

One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".

To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 10:38:01 2017
From: issues at jboss.org (John Mazzitelli (JIRA))
Date: Fri, 17 Feb 2017 10:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.42994.1487345881107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Mazzitelli updated WFLY-8161:
----------------------------------
    Issue Type: Bug  (was: Task)


> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brad Maxwell
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 10:40:00 2017
From: issues at jboss.org (Mahesh Reddy (JIRA))
Date: Fri, 17 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File
	Descriptor leak
In-Reply-To: <JIRA.12677566.1487345346000@Atlassian.JIRA>
References: <JIRA.12677566.1487345346000@Atlassian.JIRA>
	<JIRA.12677566.1487345346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677566.1487345346000.43021.1487346000843@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365579#comment-13365579 ] 

Mahesh Reddy edited comment on WFLY-8160 at 2/17/17 10:39 AM:
--------------------------------------------------------------

New file descriptors i see created for each request. Sample as below
> java    12734 megha  778r     FIFO                0,8       0t0 107360753 pipe
> java    12734 megha  779w     FIFO                0,8       0t0 107360753 pipe



was (Author: maheshvizag):
New file descriptors i see created for each request. Sample as below
> java    18967 megha *921r     FIFO                0,8       0t0 1244095284 pipe
> java    18967 megha *922w     FIFO                0,8       0t0 1244095284 pipe
> java    18967 megha *923u  a_inode                0,9         0       6115 [eventpoll]

> 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 <pid>, 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 Feb 17 11:16:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 17 Feb 2017 11:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114406@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.43312.1487348160477@Atlassian.JIRA>

Darran Lofthouse created ELY-969:
------------------------------------

             Summary: Add a KeyStore implementation that can use the key store password for retrieving entries.
                 Key: ELY-969
                 URL: https://issues.jboss.org/browse/ELY-969
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: KeyStores
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta28


A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.

In many cases the password used for the overall store is the same password as used for the entries.

We should provide a KeyStore implementation that can substitute the password received.

We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 11:36:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 11:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.43524.1487349360568@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365634#comment-13365634 ] 

Brian Stansberry commented on WFLY-8161:
----------------------------------------

This shouldn't change the property at all. There's no need to.

> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brad Maxwell
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 11:36:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 11:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.43540.1487349361272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-8161:
--------------------------------------

    Assignee: Brian Stansberry  (was: Brad Maxwell)


> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brian Stansberry
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 11:36:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 11:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.43543.1487349361390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8161:
-----------------------------------
    Priority: Critical  (was: Major)


> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 11:36:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 11:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8162) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677579.1487349341000@Atlassian.JIRA>
References: <JIRA.12677579.1487349341000@Atlassian.JIRA>
	<JIRA.12677579.1487349341555@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677579.1487349341000.43546.1487349361478@Atlassian.JIRA>

Brian Stansberry created WFLY-8162:
--------------------------------------

             Summary: JDR Subsystem destroys password related system properties
                 Key: WFLY-8162
                 URL: https://issues.jboss.org/browse/WFLY-8162
             Project: WildFly
          Issue Type: Bug
          Components: JDR
    Affects Versions: 10.0.0.Final, 10.1.0.Final
            Reporter: John Mazzitelli
            Assignee: Brian Stansberry
            Priority: Critical


When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:

https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53

One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".

To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 12:31:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 12:31:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.43813.1487352661555@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-8161:
--------------------------------------

    Assignee: Brad Maxwell  (was: Brian Stansberry)


> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brad Maxwell
>            Priority: Critical
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 12:31:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 17 Feb 2017 12:31:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8161) JDR Subsystem destroys
 password related system properties
In-Reply-To: <JIRA.12677568.1487345860000@Atlassian.JIRA>
References: <JIRA.12677568.1487345860000@Atlassian.JIRA>
	<JIRA.12677568.1487345860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677568.1487345860000.43817.1487352661692@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8161:
-----------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/9675)


> JDR Subsystem destroys password related system properties
> ---------------------------------------------------------
>
>                 Key: WFLY-8161
>                 URL: https://issues.jboss.org/browse/WFLY-8161
>             Project: WildFly
>          Issue Type: Bug
>          Components: JDR
>    Affects Versions: 10.0.0.Final, 10.1.0.Final
>            Reporter: John Mazzitelli
>            Assignee: Brad Maxwell
>            Priority: Critical
>
> When you export a JDR, it provides a report of system properties, but to avoid leaking passwords, it redacts any system property with the string &lt;Redacted> - see here:
> https://github.com/wildfly/wildfly/blob/master/jdr/jboss-as-jdr/src/main/java/org/jboss/as/jdr/commands/SystemProperties.java#L51-L53
> One major problem is it never flips the system properties back to their original values! So once a JDR report is created, no code in the JVM can ever be able to use those password system properties again - because the password is now changed to the string "&lt;Redacted>".
> To fix, once that "system-properties.txt" file is created, you have to System.setProperty() those password properties back to their original values.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 12:50:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 12:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-673) Empty result of password search
 in Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12654658.1476358891000@Atlassian.JIRA>
References: <JIRA.12654658.1476358891000@Atlassian.JIRA>
	<JIRA.12654658.1476358891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654658.1476358891000.43877.1487353800188@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-673:
------------------------------
    Fix Version/s: 1.1.0.Beta12


> Empty result of password search in Elytron ldap-realm causes NPE
> ----------------------------------------------------------------
>
>                 Key: ELY-673
>                 URL: https://issues.jboss.org/browse/ELY-673
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 1.1.0.Beta12
>
>
> In case when Elytron ldap-realm is configured to return some attribute as password (i.e. direct verification is set to false) and LDAP search does not find this attribute, then NPE occurs.
> It is caused by missing null check for {{attribute}} in [1].
> Exception thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.NullPointerException
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.getCredential(UserPasswordCredentialLoader.java:130)
> 	at org.wildfly.security.auth.realm.ldap.UserPasswordCredentialLoader$ForIdentityLoader.verifyEvidence(UserPasswordCredentialLoader.java:151)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:531)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	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)
> 	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 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: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.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)
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/cb57f2f0ffcdb1470e3135007603c97679b9434f/src/main/java/org/wildfly/security/auth/realm/ldap/UserPasswordCredentialLoader.java#L129



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 12:54:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 12:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-946) Coverity static analysis,
 suspicious bitwise logical expression, DigestUtil (Elytron)
In-Reply-To: <JIRA.12676266.1486995215000@Atlassian.JIRA>
References: <JIRA.12676266.1486995215000@Atlassian.JIRA>
	<JIRA.12676266.1486995215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676266.1486995215000.43881.1487354040102@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-946:
------------------------------
    Fix Version/s: 1.1.0.Beta25


> Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
> -------------------------------------------------------------------------------------
>
>                 Key: ELY-946
>                 URL: https://issues.jboss.org/browse/ELY-946
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 1.1.0.Beta25
>
>
> Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9563899&defectInstanceId=2359232&mergedDefectId=1377462
> See detailed description of possible problem in [1]
> If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails
> {code}
>         byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
>         assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
> {code}
> If I change decodeByteOrderedInteger implementation according to [1], all tests passes.
> {code}
> result |= (buf[offset + i] & 0xff);
> {code}
> [1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE
> Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:05:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-954) Coverity static analysis,
 Dereference null return value, OAuth2CredentialSource (Elytron)
In-Reply-To: <JIRA.12676249.1486990586000@Atlassian.JIRA>
References: <JIRA.12676249.1486990586000@Atlassian.JIRA>
	<JIRA.12676249.1486990586000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676249.1486990586000.43893.1487354700336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-954:
------------------------------
    Fix Version/s: 1.1.0.Beta26


> Coverity static analysis, Dereference null return value, OAuth2CredentialSource (Elytron)
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-954
>                 URL: https://issues.jboss.org/browse/ELY-954
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 1.1.0.Beta26
>
>
> Coverity found possible dereferencing of null value returned from {{resolveSSLContext()}} in {{openConnection()}}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=9564099&defectInstanceId=2359300&mergedDefectId=1389514
> {code:java|title=OAuth2CredentialSource.java}
>     private SSLContext resolveSSLContext() {
>         if (!isHttps(tokenEndpointUri)) {
>             return null;
>         }
>         return sslContextSupplier == null ? null : sslContextSupplier.get();
>     }
>     private HttpURLConnection openConnection() throws IOException {
>         log.debugf("Opening connection to [%s]", tokenEndpointUri);
>         HttpURLConnection connection = (HttpURLConnection) tokenEndpointUri.openConnection();
>         if (isHttps(tokenEndpointUri)) {
>             HttpsURLConnection https = (HttpsURLConnection) connection;
>             https.setSSLSocketFactory(resolveSSLContext().getSocketFactory());
>             if (hostnameVerifierSupplier != null) {
>                 https.setHostnameVerifier(checkNotNullParam("hostnameVerifier", hostnameVerifierSupplier.get()));
>             }
>         }
>         return connection;
>     }
> {code}
> NPE could probably happen if {{oauth2-introspection}} is configured with no {{client-ssl-context}} and https {{introspection-url}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:11:00 2017
From: issues at jboss.org (tech meshter (JIRA))
Date: Fri, 17 Feb 2017 13:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178533000@Atlassian.JIRA>
References: <JIRA.12677036.1487178533000@Atlassian.JIRA>
	<JIRA.12677036.1487178533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178533000.43905.1487355060109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

tech meshter updated DROOLS-1444:
---------------------------------
    Attachment: AutocloseableSample.java


> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
>                 Key: DROOLS-1444
>                 URL: https://issues.jboss.org/browse/DROOLS-1444
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: tech meshter
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:19:00 2017
From: issues at jboss.org (tech meshter (JIRA))
Date: Fri, 17 Feb 2017 13:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178533000@Atlassian.JIRA>
References: <JIRA.12677036.1487178533000@Atlassian.JIRA>
	<JIRA.12677036.1487178533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178533000.43922.1487355540277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365675#comment-13365675 ] 

tech meshter commented on DROOLS-1444:
--------------------------------------

I attached an artificial example using java.io.StringWriter (which is Autcloseable) ( [^AutocloseableSample.java] ).
In one method (desiredState) I take advantage of autocloseable feature and the syntax is pretty compact.
In another class, the autocloseable is not being used and I end up not even being able to compile the code.

Of course, the example is again artificial, just to make the point.

My actual scenario is that:
- I use drools in a Java 8 multi-user (it is a webapp) scenario
- I create one KieSession every time an user invokes that specific scenario and I want to release the resources by calling the "dispose" method.
- Inserting the objects in the KieSession using lambdas is pretty elegant (at least in my case).

Generally, the drools documentation emphasizes the need for the developer to call the "dispose" method once he is done with the KieSession (assuming he created it using a new* method on the KieBase). I see this no different that invoking close on input streams or database result sets...

Now, the AutoCloseable has been introduced in Java 7. If the intention is to keep the binaries compatible with 1.6 or below, then please forget about all this...

> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
>                 Key: DROOLS-1444
>                 URL: https://issues.jboss.org/browse/DROOLS-1444
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: tech meshter
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:20:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-924) Coverity static analysis:
 Resource leak in LdapSecurityRealm (Elytron)
In-Reply-To: <JIRA.12672985.1485348453000@Atlassian.JIRA>
References: <JIRA.12672985.1485348453000@Atlassian.JIRA>
	<JIRA.12672985.1485348453000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672985.1485348453000.43929.1487355600230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-924:
------------------------------
    Fix Version/s: 1.1.0.Beta23


> Coverity static analysis: Resource leak in LdapSecurityRealm (Elytron)
> ----------------------------------------------------------------------
>
>                 Key: ELY-924
>                 URL: https://issues.jboss.org/browse/ELY-924
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta21
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Critical
>             Fix For: 1.1.0.Beta23
>
>
> Coverity static-analysis scan found resource leak in LdapSecurityRealm.getIdentity().
> It has to be in  try-with-resources, because Stream<LdapIdentity> has registered close handler, where NamingEnumeration.close() is called. Looking into one possible implementation http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/com/sun/jndi/ldap/LdapNamingEnumeration.java#LdapNamingEnumeration It would be safer to call close() explicitelly.
> However chained stream statement is used in try, which cause 2 Stream objects to be created. But only one of them is closed. Stream created by ldapSearch.search(context) (with exlicitely registered close handler) is not closed.
> {code:java|title=LdapSecurityRealm.java}
> try (
> Stream<LdapIdentity> identityStream = ldapSearch.search(context)
>     .map(result -> new LdapIdentity(result.getNameInNamespace()))
>      ) {
>         LdapIdentity identity = identityStream.findFirst().orElse(null);
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553877&defectInstanceId=2139014&mergedDefectId=1397422



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:22:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-858) Missing search-base-dn in
 identity-mapping of Elytron ldap-realm causes NPE
In-Reply-To: <JIRA.12669012.1483358766000@Atlassian.JIRA>
References: <JIRA.12669012.1483358766000@Atlassian.JIRA>
	<JIRA.12669012.1483358766000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669012.1483358766000.43934.1487355720161@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-858:
------------------------------
    Fix Version/s: 1.1.0.Beta26


> Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
> ---------------------------------------------------------------------------
>
>                 Key: ELY-858
>                 URL: https://issues.jboss.org/browse/ELY-858
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta16
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 1.1.0.Beta26
>
>
> In case when attribute {{identity-mapping.search-base-dn}} from Elytron ldap-realm is missing in configuration then calling ldap-realm during authentication causes NullPointerException.
> Following exception is thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01108: Ldap-backed realm identity search failed
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:976)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:605)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:548)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:516)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1785)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:656)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:854)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:778)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:895)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:726)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> 	at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> 	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)
> 	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.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: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.handleRequest(ServletInitialHandler.java:104)
> 	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: java.lang.NullPointerException
> 	at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
> 	at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
> 	at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
> 	at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> 	at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> 	at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:319)
> 	at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:945)
> 	... 47 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:25:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-800) Elytron
 ExternalSaslServerFactory.createSaslServer should return null for
 unsupported policies
In-Reply-To: <JIRA.12664080.1480349099000@Atlassian.JIRA>
References: <JIRA.12664080.1480349099000@Atlassian.JIRA>
	<JIRA.12664080.1480349099000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664080.1480349099000.43939.1487355900128@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-800:
------------------------------
    Fix Version/s: 1.1.0.Beta22


> Elytron ExternalSaslServerFactory.createSaslServer should return null for unsupported policies
> ----------------------------------------------------------------------------------------------
>
>                 Key: ELY-800
>                 URL: https://issues.jboss.org/browse/ELY-800
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>             Fix For: 1.1.0.Beta22
>
>
> The {{ExternalSaslServerFactory.createSaslServer(String, String, String, Map<String, ?>, CallbackHandler)}} method returns an instance even for properties, for which {{getMechanismNames()}} returns empty array of names.
> The {{ExternalSaslServer}} instances should only be created if the mechanism is supported for given properties (configuration).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:27:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-799) Elytron
 ExternalSaslServerFactory returns EXTERNAL mechanism name when
 Sasl.POLICY_PASS_CREDENTIALS provided
In-Reply-To: <JIRA.12664059.1480345576000@Atlassian.JIRA>
References: <JIRA.12664059.1480345576000@Atlassian.JIRA>
	<JIRA.12664059.1480345576000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664059.1480345576000.43951.1487356020134@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-799:
------------------------------
    Fix Version/s: 1.1.0.Beta19


> Elytron ExternalSaslServerFactory returns EXTERNAL mechanism name when Sasl.POLICY_PASS_CREDENTIALS provided
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-799
>                 URL: https://issues.jboss.org/browse/ELY-799
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>             Fix For: 1.1.0.Beta19
>
>
> The method {{org.wildfly.security.sasl.external.ExternalSaslServerFactory.getMechanismNames(Map<String, ?>)}} returns the {{"EXTERNAL"}}?name also in cases where {{Sasl.POLICY_PASS_CREDENTIALS}} property is provided with {{"true"}} value.
> Only mechanisms which actually pass credentials should be returned for such policy (unless the special {{WildFlySasl#MECHANISM_QUERY_ALL}} property is given).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 17 13:29:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-751) Coverity static analysis:
 Explicit null dereferenced in LdapKeyStore (Elytron)
In-Reply-To: <JIRA.12661417.1479131134000@Atlassian.JIRA>
References: <JIRA.12661417.1479131134000@Atlassian.JIRA>
	<JIRA.12661417.1479131134000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661417.1479131134000.43955.1487356140235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-751:
------------------------------
    Fix Version/s: 1.1.0.Beta24


> Coverity static analysis: Explicit null dereferenced in LdapKeyStore (Elytron)
> ------------------------------------------------------------------------------
>
>                 Key: ELY-751
>                 URL: https://issues.jboss.org/browse/ELY-751
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta24
>
>
> Coverity static-analysis scan found possible use of null object in  {{LdapKeyStore}} constructor.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760194&defectInstanceId=1541374&mergedDefectId=1369294
> The {{LdapKeyStore.Builder.build()}} method constructs the {{LdapKeyStore}} instance this way:
> {code}
>   return new LdapKeyStore(spi, null, null);
> {code}
> and the constructor just calls parent ctor:
> {code}
>     protected LdapKeyStore(KeyStoreSpi keyStoreSpi, Provider provider, String type) {
>         super(keyStoreSpi, provider, type);
>     }
> {code}
> And it fails with NPE if debug for {{KeyStore}} is enabled as the constructor contains:
> {code}
>         if (!skipDebug && pdebug != null) {
>             pdebug.println("KeyStore." + type.toUpperCase() + " type from: " +
>                 this.provider.getName());
>         }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:30:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-748) Coverity static analysis:
 Explicit null dereferenced in FileSystemSecurityRealm (Elytron)
In-Reply-To: <JIRA.12661238.1479123350000@Atlassian.JIRA>
References: <JIRA.12661238.1479123350000@Atlassian.JIRA>
	<JIRA.12661238.1479123350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661238.1479123350000.43962.1487356200364@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-748:
------------------------------
    Fix Version/s: 1.1.0.Beta17


> Coverity static analysis: Explicit null dereferenced in FileSystemSecurityRealm (Elytron)
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-748
>                 URL: https://issues.jboss.org/browse/ELY-748
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta17
>
>
> Coverity static-analysis scan found possible use of null object in {{FileSystemSecurityRealm.parseCredential()}} method.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760040&defectInstanceId=1541373&mergedDefectId=1369298&eventId=1541373-14
> If the {{format}} is not provided as an attribute in the provided XML stream, then the call
> {code}
>   String format = null;
>   // ...
>   function.parseCredential(algorithm, format, text);
> {code}
> will fail for {{parsePublicKey}} method as the function code it contains code calling method of the {{format}} parameter (with possible {{null}} value).
> {code}
> if (! format.equals("pkcs8")) {
>     throw ElytronMessages.log.fileSystemRealmUnsupportedKeyFormat(format, path, streamReader.getLocation().getLineNumber(), name);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:32:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-743) Coverity static analysis:
 Dereference null return value in ServerAuthenticationContext (Elytron)
In-Reply-To: <JIRA.12660991.1478874608000@Atlassian.JIRA>
References: <JIRA.12660991.1478874608000@Atlassian.JIRA>
	<JIRA.12660991.1478874608000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660991.1478874608000.43972.1487356320367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-743:
------------------------------
    Fix Version/s: 1.1.0.Beta16


> Coverity static analysis: Dereference null return value in ServerAuthenticationContext (Elytron)
> ------------------------------------------------------------------------------------------------
>
>                 Key: ELY-743
>                 URL: https://issues.jboss.org/browse/ELY-743
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta16
>
>
> Coverity static-analysis scan found 3 possible calls on null objects in {{ServerAuthenticationContext}} class.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760324&defectInstanceId=1541382&mergedDefectId=1369286
> In {?{ServerAuthenticationContext.AuthorizedState.?isSamePrincipal(Principal)}} - Return value of function which returns null is dereferenced without checking.
> {code}
> 2039    boolean isSamePrincipal(final Principal principal) {
>     
> // 1. returned_null: getName returns null (checked 9 out of 11 times). (The virtual call resolves to org.wildfly.security.auth.server.PrincipalDecoder.<clinit>/<gen>org.wildfly.security.auth.server.PrincipalDecoder_instance_2.getName.) [show details]
>     
> // 2. var_assigned: Assigning: name = null return value from getName.
> 2040        String name = authorizedIdentity.getSecurityDomain().getPrincipalDecoder().getName(principal);
>     
> // CID 1369286 (#1 of 1): Dereference null return value (NULL_RETURNS)3. dereference: Dereferencing a pointer that might be null name when calling isSameName. [show details]
> 2041        return isSameName(name);
> 2042    }
> {code}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760324&defectInstanceId=1541377&mergedDefectId=1369289
> In {{ServerAuthenticationContext.NameAssignedState.?isSamePrincipal(Principal)}} - the same as the previous one.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760324&defectInstanceId=1541378&mergedDefectId=1369304
> In {{?ServerAuthenticationContext.ANONYMOUS.?handleOne(?Callback[], int)}}
> {code}
> 790    final PasswordCallback passwordCallback = (PasswordCallback) callback;
> 791
>    
> // 8. returned_null: getCredentialAcquireSupport returns null (checked 0 out of 1 times). [show details]
>    
> // CID 1369304 (#1 of 1): Dereference null return value (NULL_RETURNS)9. null_method_call: Calling a method on null object getCredentialAcquireSupport(org.wildfly.security.credential.PasswordCredential.class).
> 792    if (getCredentialAcquireSupport(PasswordCredential.class).mayBeSupported()) {
> {code}
> *Suggested improvement*
> Add null checks.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 17 13:33:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-741) Coverity static analysis:
 Dereference null return value in SSLConfiguratorImpl (Elytron)
In-Reply-To: <JIRA.12660973.1478872395000@Atlassian.JIRA>
References: <JIRA.12660973.1478872395000@Atlassian.JIRA>
	<JIRA.12660973.1478872395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660973.1478872395000.43975.1487356380154@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-741:
------------------------------
    Fix Version/s: 1.1.0.Beta16


> Coverity static analysis: Dereference null return value in SSLConfiguratorImpl (Elytron)
> ----------------------------------------------------------------------------------------
>
>                 Key: ELY-741
>                 URL: https://issues.jboss.org/browse/ELY-741
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta16
>
>
> Coverity static-analysis scan found 2 possible calls on null objects in {{SSLConfiguratorImpl.getDefaultSSLParameters()}} method.
> Both calls are related to following line:
> {code}
> configure(original, supportedSSLParameters.getProtocols(), supportedSSLParameters.getCipherSuites());
> {code}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5759887&defectInstanceId=1541383&mergedDefectId=1375370
> The {{getCipherSuites()}} call can return null ({{javax.net.ssl.SSLParameters.getCipherSuites}}) which can propagate to {{CipherSuiteSelector.evaluate()}} call where {{supportedMechanisms.length}} is used without null check.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5759887&defectInstanceId=1541384&mergedDefectId=1375371
> The {{getProtocols()}} call can return null ({{javax.net.ssl.SSLParameters.getProtocols}}) which can propagate to {{ProtocolSelector.evaluate()}} call where {{supportedProtocols}} is used in for loop without null check.
> *Suggested improvement*
> Add null checks.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:36:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-740) Coverity static analysis:
 Dereference null return value in EntityUtil (Elytron)
In-Reply-To: <JIRA.12660953.1478868727000@Atlassian.JIRA>
References: <JIRA.12660953.1478868727000@Atlassian.JIRA>
	<JIRA.12660953.1478868727000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660953.1478868727000.43978.1487356560113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-740:
------------------------------
    Fix Version/s: 1.1.0.Beta15


> Coverity static analysis: Dereference null return value in EntityUtil (Elytron)
> -------------------------------------------------------------------------------
>
>                 Key: ELY-740
>                 URL: https://issues.jboss.org/browse/ELY-740
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta15
>
>
> Coverity static-analysis scan found possible call on null object in {{EntityUtil.encodeAlgorithmIdentifier}} method:
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760335&defectInstanceId=1541381&mergedDefectId=1369303
> In the call
> {{encodeAlgorithmIdentifier(encoder, algorithmOid(algorithm), omitParametersField);}}
> the {{algorithmOid()}} may return null (look at {{Entity}} class).
> Then the {{encodeAlgorithmIdentifier}} calls {{DerEncoder.encodeObjectIdentifier}} where on the given String is called {{length()}} method without a null check.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:38:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-739) Coverity static analysis:
 Dereference null return value in AbstractDigestMechanism (Elytron)
In-Reply-To: <JIRA.12660947.1478868136000@Atlassian.JIRA>
References: <JIRA.12660947.1478868136000@Atlassian.JIRA>
	<JIRA.12660947.1478868136000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660947.1478868136000.43981.1487356680135@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-739:
------------------------------
    Fix Version/s: 1.1.0.Beta25


> Coverity static analysis: Dereference null return value in AbstractDigestMechanism (Elytron)
> --------------------------------------------------------------------------------------------
>
>                 Key: ELY-739
>                 URL: https://issues.jboss.org/browse/ELY-739
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta25
>
>
> Coverity static-analysis scan found 3 possible calls on null objects in {{AbstractDigestMechanism}} class:
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760450&defectInstanceId=1541368&mergedDefectId=1369283
> Method {{wrapConfidentialityProtectedMessage}}
> {code}
> cipheredPart = wrapCipher.update(toCipher);
> // ... cipheredPart may be null
> byte[] result = new byte[cipheredPart.length + 6];
> {code}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760450&defectInstanceId=1541380&mergedDefectId=1369285
> Method {{createCipher}}
> {code}
> // the getTransformationSpec may be null - look at DefaultTransformationMapper
> ciph = Cipher.getInstance(trans.getTransformationSpec(SaslMechanismInformation.Names.DIGEST_MD5, cipher).getTransformation());
> {code}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760450&defectInstanceId=1541367&mergedDefectId=1369297
> Method {{unwrapConfidentialityProtectedMessage}}
> {code}
> clearText = unwrapCipher.update(message, offset, len - 6);
> // the clearText may be null in clearText.length
> System.arraycopy(clearText, clearText.length - 10, hmac, 0, 10);
> {code}
> *Suggested improvement*
> Add null checks.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:39:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-738) Coverity static analysis:
 Dereference null return value in SingleSignOnServerMechanismFactory
 (Elytron)
In-Reply-To: <JIRA.12660934.1478866650000@Atlassian.JIRA>
References: <JIRA.12660934.1478866650000@Atlassian.JIRA>
	<JIRA.12660934.1478866650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660934.1478866650000.43984.1487356740118@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-738:
------------------------------
    Fix Version/s: 1.1.0.Beta15


> Coverity static analysis: Dereference null return value in SingleSignOnServerMechanismFactory (Elytron)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-738
>                 URL: https://issues.jboss.org/browse/ELY-738
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta15
>
>
> Coverity static-analysis scan found possible call on null object in {{SingleSignOnServerMechanismFactory.evaluateRequst()}} method:
> {code}
> getTargetMechanism(mechanismName, singleSignOnSession).evaluateRequest(createHttpServerRequest(request, singleSignOnSession));
> {code}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760259&defectInstanceId=1541379&mergedDefectId=1369284
> The problem is the {{getTargetMechanism}} call, which just calls an {{HttpServerAuthenticationMechanismFactory.createAuthenticationMechanism()}} method.
> The {{createAuthenticationMechanism}} doesn't declare it could return null, nevertheless, the implementations use null as fallback (e.g. look at {{ServerMechanismFactoryImpl.createAuthenticationMechanism()}})
> *Suggested improvement*
> I see 2 possible solutions:
> 1. Declare in javadoc of {{HttpServerAuthenticationMechanismFactory.createAuthenticationMechanism()}} method, that it can return null and add the null-check into the {{SingleSignOnServerMechanismFactory.evaluateRequst()}} method
> 2. or throw an exception from {{HttpServerAuthenticationMechanismFactory.createAuthenticationMechanism()}} implementations instead of returning null



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:42:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-737) Coverity static analysis:
 Operands don't affect result in Elytron
In-Reply-To: <JIRA.12660885.1478857664000@Atlassian.JIRA>
References: <JIRA.12660885.1478857664000@Atlassian.JIRA>
	<JIRA.12660885.1478857664000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660885.1478857664000.43989.1487356920339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-737:
------------------------------
    Fix Version/s: 1.1.0.Beta15


> Coverity static analysis: Operands don't affect result in Elytron
> -----------------------------------------------------------------
>
>                 Key: ELY-737
>                 URL: https://issues.jboss.org/browse/ELY-737
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Minor
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta15
>
>
> Coverity static-analysis scan found unnecessary code in the {{DigestQuote.quoteNeeded()}} method on line 43 (currently).
> One part of the condition is {{ch >= 0}}, which is always true, because the {{ch}} parameter has {{char}} type.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5760146&defectInstanceId=1541357&mergedDefectId=1375729
> *Suggested improvement*
> Remove the useless {{ch >= 0}} from the expression.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:44:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-733) Coverity static analysis:
 Useless call in Elytron
In-Reply-To: <JIRA.12660779.1478800398000@Atlassian.JIRA>
References: <JIRA.12660779.1478800398000@Atlassian.JIRA>
	<JIRA.12660779.1478800398000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660779.1478800398000.43998.1487357040127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-733:
------------------------------
    Fix Version/s: 1.1.0.Beta15


> Coverity static analysis: Useless call in Elytron
> -------------------------------------------------
>
>                 Key: ELY-733
>                 URL: https://issues.jboss.org/browse/ELY-733
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Minor
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta15
>
>
> Coverity static analysis: Useless call in Elytron
> Coverity static-analysis scan found useless call in the {{FileSystemSecurityRealm.writeIdentity()}} method on line 554 (currently).
> There is an orphan call of {{otp.getHash()}}.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5721630&defectInstanceId=1531117&mergedDefectId=1369308
> The correct call is on the line 557, where it's used in streamWriter.
> *Suggested improvement*
> Remove the useless call.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:46:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-731) Coverity static analysis:
 Missing parent calls in Elytron
In-Reply-To: <JIRA.12660462.1478700606000@Atlassian.JIRA>
References: <JIRA.12660462.1478700606000@Atlassian.JIRA>
	<JIRA.12660462.1478700606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660462.1478700606000.44001.1487357160616@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-731:
------------------------------
    Fix Version/s: 1.1.0.Beta15


> Coverity static analysis: Missing parent calls in Elytron
> ---------------------------------------------------------
>
>                 Key: ELY-731
>                 URL: https://issues.jboss.org/browse/ELY-731
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Minor
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta15
>
>
> Coverity static-analysis scan found missing parent calls in Elytron. They seems to be a simple fixes:
> * DisposedCallbackSaslClientFactory should use super.dispose() instead of delegate.dispose()
> ** https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5621921&defectInstanceId=1486715&mergedDefectId=1369275
> * DisposedCallbackSaslServerFactory should use super.dispose() instead of delegate.dispose()
> ** https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5621887&defectInstanceId=1486717&mergedDefectId=1369279
> * org.wildfly.security.auth.client.MatchSchemeSpecificPartRule.matches(URI, String, String, String)
> ** compare to {{MatchHostRule}} class
> ** https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=5622496&defectInstanceId=1486714&mergedDefectId=1375739



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:49:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-664) Ensure that the "index"
 attribute in AttributeMapper is greater than 1.
In-Reply-To: <JIRA.12655011.1476475818000@Atlassian.JIRA>
References: <JIRA.12655011.1476475818000@Atlassian.JIRA>
	<JIRA.12655011.1476475818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655011.1476475818000.44002.1487357340060@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-664:
------------------------------
    Fix Version/s: 1.1.0.Beta12


> Ensure that the "index" attribute in AttributeMapper is greater than 1. 
> ------------------------------------------------------------------------
>
>                 Key: ELY-664
>                 URL: https://issues.jboss.org/browse/ELY-664
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta10
>            Reporter: Ilia Vassilev
>            Assignee: Ilia Vassilev
>             Fix For: 1.1.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 13:56:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 13:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-831) Coverity static analysis:
 Resource leak in OidsUtil (Elytron)
In-Reply-To: <JIRA.12667649.1481728355000@Atlassian.JIRA>
References: <JIRA.12667649.1481728355000@Atlassian.JIRA>
	<JIRA.12667649.1481728355000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667649.1481728355000.44017.1487357760124@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-831:
------------------------------
    Fix Version/s: 1.1.0.Beta19


> Coverity static analysis: Resource leak in OidsUtil (Elytron)
> -------------------------------------------------------------
>
>                 Key: ELY-831
>                 URL: https://issues.jboss.org/browse/ELY-831
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta19
>
>
> Coverity static-analysis scan found resource leak in {{OidsUtil}} static initialization block.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=6804056&defectInstanceId=1776762&mergedDefectId=1384493
> Following code is used in the static block
> {code}
> props.load(OidsUtil.class.getResourceAsStream("oids.properties"));
> {code}
> The resource created by {{OidsUtil.class.getResourceAsStream("oids.properties")}} is not closed properly.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 14:20:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 17 Feb 2017 14:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-830) Coverity static analysis:
 Resource leak in KeyStoreCredentialStore (Elytron)
In-Reply-To: <JIRA.12667645.1481728185000@Atlassian.JIRA>
References: <JIRA.12667645.1481728185000@Atlassian.JIRA>
	<JIRA.12667645.1481728185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667645.1481728185000.44098.1487359200254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-830:
------------------------------
    Fix Version/s: 1.1.0.Beta19


> Coverity static analysis: Resource leak in KeyStoreCredentialStore (Elytron)
> ----------------------------------------------------------------------------
>
>                 Key: ELY-830
>                 URL: https://issues.jboss.org/browse/ELY-830
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Josef Cacek
>            Assignee: Ilia Vassilev
>            Priority: Critical
>              Labels: static_analysis
>             Fix For: 1.1.0.Beta19
>
>
> Coverity static-analysis scan found resource leak in {{KeyStoreCredentialStore.load(String)}} method.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=6803973&defectInstanceId=1776761&mergedDefectId=1388282
> The method calls
> {code}
> keyStore.load(Files.newInputStream(location), getStorePassword(protectionParameter));
> {code}
> The resource {{java.nio.file.Files.newInputStream(location)}} is not closed in the {{load}} method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 17 16:33:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 17 Feb 2017 16:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8158) JSP source code leak when
 space and periods added at the end of the URL
In-Reply-To: <JIRA.12677510.1487332335000@Atlassian.JIRA>
References: <JIRA.12677510.1487332335000@Atlassian.JIRA>
	<JIRA.12677510.1487332335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677510.1487332335000.44293.1487367180245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFLY-8158.
----------------------------------
    Resolution: Duplicate Issue


Duplicate of UNDERTOW-576 which was fixed by https://github.com/undertow-io/undertow/commit/b1df3310f50a7cf45160194a18f15dc4ddc623bb

> JSP source code leak when space and periods added at the end of the URL
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8158
>                 URL: https://issues.jboss.org/browse/WFLY-8158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: WildFly executing on Windows
>            Reporter: Markus Markus
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> All of the following requests will return the jsp file content untransformed, meaning that the actual content of the jsp-file is returned to the browser.
> {code}
> http://localhost:8080/application/HostPage.jsp%2E
> http://localhost:8080/application/HostPage.jsp%2E%2E
> http://localhost:8080/application/HostPage.jsp%20%2E
> http://localhost:8080/application/HostPage.jsp%20%2E%2E
> {code}
> The problem with periods has perhaps to do with windows removing/accepting trailing periods in file names: [here|http://stackoverflow.com/questions/17746494/why-is-directory-name-which-contains-dots-in-the-end-is-treated-as-a-directory], [and here|http://stackoverflow.com/questions/11681207/how-to-create-a-filename-with-a-trailing-period-in-windows/16203594#16203594] because {{io.undertow.server.handlers.resource.FileResourceManager.getResource()}} delegates to {{java.io.File}} to test whether a file path is valid or not, and {{java.io.File}} does presumably delegate to Windows.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 09:45:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 09:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2308) Upgrade DMR to 1.4.0.Beta2
In-Reply-To: <JIRA.12677643.1487429086000@Atlassian.JIRA>
References: <JIRA.12677643.1487429086000@Atlassian.JIRA>
	<JIRA.12677643.1487429086984@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677643.1487429086000.44475.1487429100069@Atlassian.JIRA>

Brian Stansberry created WFCORE-2308:
----------------------------------------

             Summary: Upgrade DMR to 1.4.0.Beta2
                 Key: WFCORE-2308
                 URL: https://issues.jboss.org/browse/WFCORE-2308
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 11:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1962) Deprecate
 ParameterValidator.validateResolvedParameter, try and get rid of uses of it
In-Reply-To: <JIRA.12660247.1478625712000@Atlassian.JIRA>
References: <JIRA.12660247.1478625712000@Atlassian.JIRA>
	<JIRA.12660247.1478625712000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660247.1478625712000.44523.1487435640079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1962:
----------------------------------------

      Assignee: Brian Stansberry
    Resolution: Done


> Deprecate ParameterValidator.validateResolvedParameter, try and get rid of uses of it
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1962
>                 URL: https://issues.jboss.org/browse/WFCORE-1962
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta3
>
>
> The ParameterValidator.validateResolvedParameter method specifies the impl should call ModelNode.resolve() and then validate that. This is a broken contract as ModelNode.resolve() is not the expression resolution mechanism of WildFly.
> This code is only used in a few places. The normal way resolution + validation happens is outside code (e.g. AttributeDefinition) resolves the value and then calls the normal ParameterValidator.validateParameter method.
> So, task here is to look into the few uses of this method in core and full, determine they can be changed to no longer use it, change them, then deprecate this method.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 11:36:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 11:36: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.44529.1487435760400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2301:
-------------------------------------
    Fix Version/s: 2.2.1.Final


> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Sat Feb 18 11:36:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 11:36: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.44526.1487435760216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reopened WFCORE-2301:
--------------------------------------


> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Sat Feb 18 11:37:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 11:37: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.44532.1487435820084@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365744#comment-13365744 ] 

Brian Stansberry commented on WFCORE-2301:
------------------------------------------

Should be fixed for WF 11, at least if the Files.getFileStore issue is the only thing affected by the JDK bug. I'm leaving this unresolved for now as I may backport this to WildFly Core 2.2.1.

> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Sat Feb 18 13:54:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:03 -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: <JIRA.12677290.1487258960000@Atlassian.JIRA>
References: <JIRA.12677290.1487258960000@Atlassian.JIRA>
	<JIRA.12677290.1487258960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677290.1487258960000.44655.1487444043851@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:03 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2301) Mount point not found
 exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
In-Reply-To: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.44658.1487444043910@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Beta4, 2.2.1.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Sat Feb 18 13:54:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.44665.1487444044134@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.44673.1487444044340@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.44676.1487444044387@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2217:
-------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta4, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Sat Feb 18 13:54:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:04 -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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.44690.1487444044948@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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  Sat Feb 18 13:54:04 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.44683.1487444044685@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.44700.1487444045257@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:05 -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: <JIRA.12666705.1481282688000@Atlassian.JIRA>
References: <JIRA.12666705.1481282688000@Atlassian.JIRA>
	<JIRA.12666705.1481282688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666705.1481282688000.44707.1487444045477@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:05 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron
	1.1.0.Final
In-Reply-To: <JIRA.12666683.1481279343000@Atlassian.JIRA>
References: <JIRA.12666683.1481279343000@Atlassian.JIRA>
	<JIRA.12666683.1481279343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666683.1481279343000.44714.1487444045806@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.44723.1487444046004@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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  Sat Feb 18 13:54:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.44729.1487444046143@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.44737.1487444046455@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>         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  Sat Feb 18 13:54:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:06 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.44745.1487444046748@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:06 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.44748.1487444046840@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta4
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:07 -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: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.44758.1487444047297@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>         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<String, String>, 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  Sat Feb 18 13:54:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.44763.1487444047466@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:07 -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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.44770.1487444047778@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.44755.1487444047174@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1964:
-------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta4
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:07 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.44776.1487444047937@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.44784.1487444048238@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:08 -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: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.44788.1487444048370@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:08 -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: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.44796.1487444048705@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:08 -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: <JIRA.12626950.1463652179000@Atlassian.JIRA>
References: <JIRA.12626950.1463652179000@Atlassian.JIRA>
	<JIRA.12626950.1463652179000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626950.1463652179000.44799.1487444048819@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>         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  Sat Feb 18 13:54:08 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1441) Threads resource classes
 should make it easy for users to declare capabilities
In-Reply-To: <JIRA.12610985.1458236449000@Atlassian.JIRA>
References: <JIRA.12610985.1458236449000@Atlassian.JIRA>
	<JIRA.12610985.1458236449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610985.1458236449000.44801.1487444048866@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1441:
-------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> Threads resource classes should make it easy for users to declare capabilities
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-1441
>                 URL: https://issues.jboss.org/browse/WFCORE-1441
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta4
>
>
> The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking.
> But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities.
> Things probably needed:
> 1) Ability to declare the capability that should be registered when a resource is created.
> 2) Ability to declare the capability that model reference attributes in a resource refer to.
> Perhaps others, but those are the ones that come immediately to mind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:09 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:09 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.44812.1487444049217@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Beta4
>
>         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 Feb 18 13:54:09 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:09 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.44821.1487444049625@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>         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  Sat Feb 18 13:54:09 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.44830.1487444049869@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:09 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.44833.1487444049930@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> "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.Beta4
>
>
> 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  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.44845.1487444050367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-459:
------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta4
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.44848.1487444050446@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:09 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.44826.1487444049736@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.44851.1487444050559@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-266:
------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta4
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.44840.1487444050170@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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.<init>(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  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.44854.1487444050672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-107:
------------------------------------
    Fix Version/s: 3.0.0.Beta4
                       (was: 3.0.0.Beta3)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta4
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sat Feb 18 13:54:10 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 18 Feb 2017 13:54:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.44859.1487444050796@Atlassian.JIRA>


     [ 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.Beta4
                       (was: 3.0.0.Beta3)


> 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.Beta4
>
>
> 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  Sun Feb 19 06:19:00 2017
From: issues at jboss.org (ebuzer taha kanat (JIRA))
Date: Sun, 19 Feb 2017 06:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-393) Missing jboss-web_10_0.xsd
	on jboss.org
In-Reply-To: <JIRA.12615723.1461062356000@Atlassian.JIRA>
References: <JIRA.12615723.1461062356000@Atlassian.JIRA>
	<JIRA.12615723.1461062356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615723.1461062356000.44998.1487503140164@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBMETA-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365781#comment-13365781 ] 

ebuzer taha kanat commented on JBMETA-393:
------------------------------------------

Referenced file contains errors (http://www.jboss.org/schema/jbossas/jboss-web_10_0.xsd)

> Missing jboss-web_10_0.xsd on jboss.org
> ---------------------------------------
>
>                 Key: JBMETA-393
>                 URL: https://issues.jboss.org/browse/JBMETA-393
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>            Reporter: Ladislav Thon
>            Assignee: Jean-Frederic Clere
>            Priority: Critical
>
> The {{jboss-web_10_0.xsd}} file we ship with WildFly 10 says at the beginning:
> {code:xml}
>         <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
>            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>            xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
>            version="10.0">
> 	       ...
>         </jboss-web>
> 	Instance documents may indicate the published version of
> 	the schema using the xsi:schemaLocation attribute for the
> 	Java EE namespace with the following location:
> 	http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd
> {code}
> So we're pointing people to http://www.jboss.org/j2ee/schema/, which is a seemingly arbitrary collection of fairly old files that definitely doesn't contain {{jboss-web_10_0.xsd}}.
> This seems to also be the case for XSDs in previously shipped products, e.g. all {{jboss-web_7_*.xsd}} files in EAP 6.4 point to the same location.
> I found that http://www.jboss.org/schema/jbossas/ contains a more modern set of XSDs, but:
> - we don't point to it, at least not from {{jboss-web_*.xsd}} files
> - it doesn't contain {{jboss-web_10_0.xsd}}
> I think the second point should be fairly easy to fix. Hope this is not the wrong place to report this :-)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 19 15:49:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 19 Feb 2017 15:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8163) Review hard coded of
 jboss-ejb-policy in
 EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
In-Reply-To: <JIRA.12677662.1487537333000@Atlassian.JIRA>
References: <JIRA.12677662.1487537333000@Atlassian.JIRA>
	<JIRA.12677662.1487537333707@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677662.1487537333000.45113.1487537340180@Atlassian.JIRA>

Stuart Douglas created WFLY-8163:
------------------------------------

             Summary: Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
                 Key: WFLY-8163
                 URL: https://issues.jboss.org/browse/WFLY-8163
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Stuart Douglas
            Assignee: Darran Lofthouse


This dep is hard coded because it was required by picketbox, however now that elytron is in we should not be creating picketbox dependencies by default.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 19 17:07:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 19 Feb 2017 17:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8163) Review hard coded of
 jboss-ejb-policy in
 EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
In-Reply-To: <JIRA.12677662.1487537334000@Atlassian.JIRA>
References: <JIRA.12677662.1487537334000@Atlassian.JIRA>
	<JIRA.12677662.1487537334000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677662.1487537334000.45164.1487542020323@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8163:
------------------------------------

    Assignee: Stuart Douglas  (was: Darran Lofthouse)


> Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8163
>                 URL: https://issues.jboss.org/browse/WFLY-8163
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This dep is hard coded because it was required by picketbox, however now that elytron is in we should not be creating picketbox dependencies by default.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 00:13:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 00:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI
	@Stereotype
In-Reply-To: <JIRA.12677166.1487238895000@Atlassian.JIRA>
References: <JIRA.12677166.1487238895000@Atlassian.JIRA>
	<JIRA.12677166.1487238895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677166.1487238895000.45312.1487567580297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8136:
------------------------------------

    Assignee: Alessio Soldano  (was: Stuart Douglas)


> 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
>    Affects Versions: 9.0.1.Final
>         Environment: Windows 7, JDK 1.8.0_60
>            Reporter: Andreas Klemp
>            Assignee: Alessio Soldano
>
> 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  Mon Feb 20 00:13:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 00:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI
	@Stereotype
In-Reply-To: <JIRA.12677166.1487238895000@Atlassian.JIRA>
References: <JIRA.12677166.1487238895000@Atlassian.JIRA>
	<JIRA.12677166.1487238895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677166.1487238895000.45318.1487567580487@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-8136:
---------------------------------
    Component/s: REST


> 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: Alessio Soldano
>
> 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  Mon Feb 20 00:14:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 00:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8064) Dependecy Injection not
	working
In-Reply-To: <JIRA.12675715.1486640123000@Atlassian.JIRA>
References: <JIRA.12675715.1486640123000@Atlassian.JIRA>
	<JIRA.12675715.1486640123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675715.1486640123000.45323.1487567640286@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8064:
------------------------------------

    Assignee: Alessio Soldano  (was: Stuart Douglas)


> Dependecy Injection not working
> -------------------------------
>
>                 Key: WFLY-8064
>                 URL: https://issues.jboss.org/browse/WFLY-8064
>             Project: WildFly
>          Issue Type: Release
>          Components: CDI / Weld
>    Affects Versions: 10.0.0.Final
>         Environment: Windows 2012 R2
>            Reporter: Pradeep Ganapathy
>            Assignee: Alessio Soldano
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>   
>   @Inject
>  private ITestDAO dao;
>   public TestImpl setTestDAO(ITestDAO dao)
>   {
>    this.dao = dao;
>    return this;
>   }
>   @Inject 
> private TestDescription testDescription;
>   public TestImpl setTestDescription(TestDescription testDescription)
>   {
>    this.testDescription = testDescription;
>    return this;
>   }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
>   at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
>   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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>   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:395)
>   ... 35 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 00:14:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 00:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8064) Dependecy Injection not
	working
In-Reply-To: <JIRA.12675715.1486640123000@Atlassian.JIRA>
References: <JIRA.12675715.1486640123000@Atlassian.JIRA>
	<JIRA.12675715.1486640123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675715.1486640123000.45330.1487567640604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-8064:
---------------------------------
    Component/s: REST


> Dependecy Injection not working
> -------------------------------
>
>                 Key: WFLY-8064
>                 URL: https://issues.jboss.org/browse/WFLY-8064
>             Project: WildFly
>          Issue Type: Release
>          Components: CDI / Weld, REST
>    Affects Versions: 10.0.0.Final
>         Environment: Windows 2012 R2
>            Reporter: Pradeep Ganapathy
>            Assignee: Alessio Soldano
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>   
>   @Inject
>  private ITestDAO dao;
>   public TestImpl setTestDAO(ITestDAO dao)
>   {
>    this.dao = dao;
>    return this;
>   }
>   @Inject 
> private TestDescription testDescription;
>   public TestImpl setTestDescription(TestDescription testDescription)
>   {
>    this.testDescription = testDescription;
>    return this;
>   }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
>   at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
>   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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>   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:395)
>   ... 35 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 01:11:00 2017
From: issues at jboss.org (Mahesh Reddy (JIRA))
Date: Mon, 20 Feb 2017 01:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File
	Descriptor leak
In-Reply-To: <JIRA.12677566.1487345346000@Atlassian.JIRA>
References: <JIRA.12677566.1487345346000@Atlassian.JIRA>
	<JIRA.12677566.1487345346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677566.1487345346000.45348.1487571060199@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mahesh Reddy updated WFLY-8160:
-------------------------------
    Attachment: BioMatcherWebserviceImpl.java


> 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, 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 <pid>, 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  Mon Feb 20 01:22:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 20 Feb 2017 01:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.45354.1487571720092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365828#comment-13365828 ] 

Martin Choma commented on ELY-969:
----------------------------------

Does that mean another resource will be created or is this issue talking about changing existing keystore resource.

To be honest it does not look to me much practical. If for achieving "default key password"  another resource have to be registered. And if this will be only additional feature of this new resource.

> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 02:25:00 2017
From: issues at jboss.org (Michal Jurc (JIRA))
Date: Mon, 20 Feb 2017 02:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8164) Review hard coded of
 jboss-ejb-policy in
 EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
In-Reply-To: <JIRA.12677686.1487575466000@Atlassian.JIRA>
References: <JIRA.12677686.1487575466000@Atlassian.JIRA>
	<JIRA.12677686.1487575466795@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677686.1487575466000.45439.1487575500471@Atlassian.JIRA>

Michal Jurc created WFLY-8164:
---------------------------------

             Summary: Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure
                 Key: WFLY-8164
                 URL: https://issues.jboss.org/browse/WFLY-8164
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Michal Jurc
            Assignee: Stuart Douglas


This dep is hard coded because it was required by picketbox, however now that elytron is in we should not be creating picketbox dependencies by default.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 02:34:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 02:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-42) Treat EAP immutable if
 running in Container
In-Reply-To: <JIRA.12677340.1487270316000@Atlassian.JIRA>
References: <JIRA.12677340.1487270316000@Atlassian.JIRA>
	<JIRA.12677340.1487270316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677340.1487270316000.45471.1487576040339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan deleted HAWKULARQE-42:
-------------------------------------


> Treat EAP immutable if running in Container
> -------------------------------------------
>
>                 Key: HAWKULARQE-42
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-42
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>
> See https://issues.jboss.org/browse/HAWKULAR-1183



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:22:03 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 03:22:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-970) Elytron Ldap Realm searches
 roles before validating password when direct verification and referral mode
 follow are used
In-Reply-To: <JIRA.12677692.1487578920000@Atlassian.JIRA>
References: <JIRA.12677692.1487578920000@Atlassian.JIRA>
	<JIRA.12677692.1487578920875@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677692.1487578920000.45727.1487578923406@Atlassian.JIRA>

Ondrej Lukas created ELY-970:
--------------------------------

             Summary: Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used
                 Key: ELY-970
                 URL: https://issues.jboss.org/browse/ELY-970
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
# searching for username
# searching for roles (i.e. searching for attributes)
# validating password for username

It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.

This is the same issue as JBEAP-7339 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:23:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 03:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-970) Elytron Ldap Realm searches
 roles before validating password when direct verification and referral mode
 follow are used
In-Reply-To: <JIRA.12677692.1487578921000@Atlassian.JIRA>
References: <JIRA.12677692.1487578921000@Atlassian.JIRA>
	<JIRA.12677692.1487578921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677692.1487578921000.45730.1487578980258@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-970:
-----------------------------
    Description: 
In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
# searching for username
# searching for roles (i.e. searching for attributes)
# validating password for username

It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.

This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.

  was:
In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
# searching for username
# searching for roles (i.e. searching for attributes)
# validating password for username

It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.

This is the same issue as JBEAP-7339 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.



> Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-970
>                 URL: https://issues.jboss.org/browse/ELY-970
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
> # searching for username
> # searching for roles (i.e. searching for attributes)
> # validating password for username
> It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.
> This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:23:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 03:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-970) Elytron Ldap Realm searches
 roles before validating password when direct verification and referral mode
 follow are used
In-Reply-To: <JIRA.12677692.1487578921000@Atlassian.JIRA>
References: <JIRA.12677692.1487578921000@Atlassian.JIRA>
	<JIRA.12677692.1487578921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677692.1487578921000.45733.1487578980360@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-970:
-----------------------------
    Component/s: Realms


> Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-970
>                 URL: https://issues.jboss.org/browse/ELY-970
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
> # searching for username
> # searching for roles (i.e. searching for attributes)
> # validating password for username
> It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.
> This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:24:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 03:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-970) Elytron Ldap Realm searches
 roles before validating password when direct verification and referral mode
 follow are used
In-Reply-To: <JIRA.12677692.1487578921000@Atlassian.JIRA>
References: <JIRA.12677692.1487578921000@Atlassian.JIRA>
	<JIRA.12677692.1487578921000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677692.1487578921000.45736.1487579040097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-970:
-----------------------------
    Affects Version/s: 1.1.0.Beta25


> Elytron Ldap Realm searches roles before validating password when direct verification and referral mode follow are used
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-970
>                 URL: https://issues.jboss.org/browse/ELY-970
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>    Affects Versions: 1.1.0.Beta25
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when Ldap Realm is set to use direct verification and referenced DirContext uses referral mode follow, then roles for referral user are searched before actual user password is validated. In this case following flow is used:
> # searching for username
> # searching for roles (i.e. searching for attributes)
> # validating password for username
> It means even if wrong password is used then roles in LDAP are searched. Password should be validated before some roles are searched. Current behavior can result to performance issues.
> This is the same issue as ELY-760 but only for case when direct verification and referral mode follow are used and user from referral tries to authenticate.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:25:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 20 Feb 2017 03:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579054000@Atlassian.JIRA>
References: <JIRA.12677693.1487579054000@Atlassian.JIRA>
	<JIRA.12677693.1487579054904@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579054000.45739.1487579100192@Atlassian.JIRA>

Matteo Mortari created DROOLS-1445:
--------------------------------------

             Summary: Mask should reflect properties accessed in other nodes join constraints
                 Key: DROOLS-1445
                 URL: https://issues.jboss.org/browse/DROOLS-1445
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Matteo Mortari
            Assignee: Mario Fusco


The following test exhibit a failing and a working test:

{code:java}
    @Test()
    public void testAbis_NotWorking() {
        // DROOLS-644
        String drl =
                "import " + Person.class.getCanonicalName() + ";\n" +
                "global java.util.List list;\n" +
                "rule R when\n" +
                "    $p1 : Person( name == \"Mario\" ) \n" +
                "    $p2 : Person( age > $p1.age ) \n" +
                "then\n" +
                "    list.add(\"t0\");\n" +
                "end\n" +
                "rule Z when\n" +
                "    $p1 : Person( name == \"Mario\" ) \n" +
                "then\n" +
                "    modify($p1) { setAge(35); } \n" +
                "end\n" 
                ;
        
        // making the default explicit:
        KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
                .build()
                .newKieSession();
        ksession.addEventListener(new DebugAgendaEventListener());
        System.out.println(drl);
        ReteDumper.dumpRete(ksession);

        List<String> list = new ArrayList<String>();
        ksession.setGlobal("list", list);

        Person mario = new Person("Mario", 40);
        Person mark = new Person("Mark", 37);
        FactHandle fh_mario = ksession.insert(mario);
        ksession.insert(mark);
        int x = ksession.fireAllRules();
        assertEquals(1, list.size());
        assertEquals("t0", list.get(0));
    }
    
    @Test()
    public void testAbis_Working() {
        // DROOLS-644
        String drl =
                "import " + Person.class.getCanonicalName() + ";\n" +
                "global java.util.List list;\n" +
                "rule R when\n" +
                "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
                "    $p2 : Person( age > $a1 ) \n" +
                "then\n" +
                "    list.add(\"t0\");\n" +
                "end\n" +
                "rule Z when\n" +
                "    $p1 : Person( name == \"Mario\" ) \n" +
                "then\n" +
                "    modify($p1) { setAge(35); } \n" +
                "end\n" 
                ;

        // making the default explicit:
        KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
                .build()
                .newKieSession();
        
        System.out.println(drl);
        ReteDumper.dumpRete(ksession);

        List<String> list = new ArrayList<String>();
        ksession.setGlobal("list", list);

        Person mario = new Person("Mario", 40);
        Person mark = new Person("Mark", 37);
        FactHandle fh_mario = ksession.insert(mario);
        ksession.insert(mark);
        int x = ksession.fireAllRules();
        assertEquals(1, list.size());
        assertEquals("t0", list.get(0));
    }
{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:52:00 2017
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 20 Feb 2017 03:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8064) Dependecy Injection not
	working
In-Reply-To: <JIRA.12675715.1486640123000@Atlassian.JIRA>
References: <JIRA.12675715.1486640123000@Atlassian.JIRA>
	<JIRA.12675715.1486640123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675715.1486640123000.46001.1487580720221@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365894#comment-13365894 ] 

Alessio Soldano commented on WFLY-8064:
---------------------------------------

indeed... [~gprade], please provide a reproducer, thanks

> Dependecy Injection not working
> -------------------------------
>
>                 Key: WFLY-8064
>                 URL: https://issues.jboss.org/browse/WFLY-8064
>             Project: WildFly
>          Issue Type: Release
>          Components: CDI / Weld, REST
>    Affects Versions: 10.0.0.Final
>         Environment: Windows 2012 R2
>            Reporter: Pradeep Ganapathy
>            Assignee: Alessio Soldano
>
> All injected parameters after post construct are null. Jboss cant able to detect inject paramaters. Both dao and testDescription parameters are null. As a result null pointer exception
> RestEasy versions(All) ----> 3.0.14.Final.
> ApplicationScoped
> public class TestImpl implements ITest
> {
>   
>   @Inject
>  private ITestDAO dao;
>   public TestImpl setTestDAO(ITestDAO dao)
>   {
>    this.dao = dao;
>    return this;
>   }
>   @Inject 
> private TestDescription testDescription;
>   public TestImpl setTestDescription(TestDescription testDescription)
>   {
>    this.testDescription = testDescription;
>    return this;
>   }
> }
> Error Logs:
> 2017-02-09 13:11:22,256 ERROR [io.undertow.request] (default task-128) UT005023: Exception handling request to( My EndPoint): org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> Caused by: java.lang.NullPointerException
>   at ServiceRegistryImpl.lookup(ServiceRegistryImpl.java:142)
>   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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
>   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:395)
>   ... 35 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 03:57:00 2017
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Mon, 20 Feb 2017 03:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8160) Webservice response File
	Descriptor leak
In-Reply-To: <JIRA.12677566.1487345346000@Atlassian.JIRA>
References: <JIRA.12677566.1487345346000@Atlassian.JIRA>
	<JIRA.12677566.1487345346000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677566.1487345346000.46024.1487581020225@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-8160:
----------------------------------
    Attachment:     (was: BioMatcherWebserviceImpl.java)


> 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 <pid>, 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  Mon Feb 20 05:25:00 2017
From: issues at jboss.org (Rostislav Svoboda (JIRA))
Date: Mon, 20 Feb 2017 05:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1529) New threads named
 ServerService Thread Pool -- xyz created with every deploy and undeploy and
 removed after ~20 seconds
In-Reply-To: <JIRA.12618367.1462469743000@Atlassian.JIRA>
References: <JIRA.12618367.1462469743000@Atlassian.JIRA>
	<JIRA.12618367.1462469743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618367.1462469743000.46808.1487586300312@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365984#comment-13365984 ] 

Rostislav Svoboda commented on WFCORE-1529:
-------------------------------------------

https://github.com/wildfly/wildfly-core/pull/2164/files

> New threads named ServerService Thread Pool -- xyz created with every deploy and undeploy and removed after ~20 seconds
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1529
>                 URL: https://issues.jboss.org/browse/WFCORE-1529
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.1.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 3.0.0.Beta3
>
>
> tl;dr version from Brian:
> The ServerService Threads and Host Controller Service Threads pools have no core size and a thread timeout of 20 secs, so if a management request comes in periodically but less often then every 20 secs (says twice a minute) the pool will continually churn threads. That kind of periodic polling is not an unusual scenario, so, we'll put in a core size of one or two.
> Original details from Rostislav:
> I did quite simple thing in the loop : 
>  * deploy attached application into jboss-eap-7.0/standalone/deployments/
>  * wait 1 minute
>  * remove anything from jboss-eap-7.0/standalone/deployments/
>  * wait 1 minute
> I connected with jvisualvm and was watching monitor tab for cpu / classes / heap / threads overview statistics. After some time I spotted jumps (up and down) on threads.
> After some time I see threads named "ServerService Thread Pool -- 346", I ended with number bigger than 1400. In my case 15 threads are created for 20 seconds when deploying and another 15 threads are created for 20 seconds when undeploying. Nothing seems to be reused
> Setup for threads is done in https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/ServerService.java#L207-L213 method addService
> Is it intentional to have threads alive only 20 seconds and then scratch them ? Keeping a lot of threads means usage of system resources, creating new threads has some overhead too. Maybe the question is what is the right balance ? 
> Note: It would be nice to have "Possible Bug" Issue Type for issues like this ;)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 05:30:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 05:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.46833.1487586600533@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13365991#comment-13365991 ] 

Darran Lofthouse commented on ELY-969:
--------------------------------------

No within the subsystem it will not require an additional resource - that would not solve the problem this change is intended to solve at all.


> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 05:41:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 05:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178533000@Atlassian.JIRA>
References: <JIRA.12677036.1487178533000@Atlassian.JIRA>
	<JIRA.12677036.1487178533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178533000.46928.1487587260443@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366003#comment-13366003 ] 

Mario Fusco commented on DROOLS-1444:
-------------------------------------

In that example you're showing how to use try-with-resource with the StringWriter. That makes perfectly sense to me but it is not what I was asking. I was asking for a practical example using the KieSession because in my opinion in that case it is not that useful and using a try-with-resource is more verbose and cumbersome than simply adding a dispose. 

I cannot add this to drools 6.x because it has to stay Java 6 compatible, but I could do this on master (drools 7) that is Java 8 based. However I really don't see the usefulness in doing so. Moreover your scenario seems to fit far better a StatelessKieSession which doesn't require any dispose. Did you give it a try?

> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
>                 Key: DROOLS-1444
>                 URL: https://issues.jboss.org/browse/DROOLS-1444
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: tech meshter
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 05:41:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 05:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1444) KieSession to implement
 java.lang.AutoCloseable
In-Reply-To: <JIRA.12677036.1487178533000@Atlassian.JIRA>
References: <JIRA.12677036.1487178533000@Atlassian.JIRA>
	<JIRA.12677036.1487178533000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677036.1487178533000.46932.1487587260551@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1444.
---------------------------------
    Resolution: Rejected


> KieSession to implement java.lang.AutoCloseable
> -----------------------------------------------
>
>                 Key: DROOLS-1444
>                 URL: https://issues.jboss.org/browse/DROOLS-1444
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: tech meshter
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: AutocloseableSample.java
>
>
> Given the new Java 7 and 8 syntax features, it would be useful that KieSession (and maybe some other APIs that involve "disposability") to implement java.lang.AutoCloseable. The implementation can call directly the "dispose" method (unless I miss something) and over time dispose might become deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 05:47:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 20 Feb 2017 05:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.46962.1487587620172@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366006#comment-13366006 ] 

Martin Choma commented on ELY-969:
----------------------------------

So in terms of subsystem; Key password of key-manager could become optional. And elytron keystore implementation will "default" key-password with keystore password - I am OK with such enhancement. 

Regarding "password for different entries". I thought multiple keys will be handled by filter-alias on key-manager (https://issues.jboss.org/browse/WFLY-7158). It means effectivelly filter keys to one and provide key-password for that one. 

So I am not sure how is this "password for different entries" meant on KeyStore level.

> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 05:51:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 05:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.46992.1487587860770@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366011#comment-13366011 ] 

Darran Lofthouse commented on ELY-969:
--------------------------------------

At the key store level we could have the option of defining different filters and each of those being associated with a different credential reference - we could then aggregate the results together giving you one KeyStore able to return different entries using a different protection parameter for each.

> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 06:17:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 20 Feb 2017 06:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.47160.1487589421029@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reopened WFLY-7322:
------------------------------


Reopen: DIRECT verification still not work with FOLLOW mode

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 06:20:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 20 Feb 2017 06:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.47222.1487589600760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomas Hofman updated ELY-880:
-----------------------------
     Original Estimate: 3 days
    Remaining Estimate: 3 days


> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 06:47:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 06:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4
In-Reply-To: <JIRA.12677747.1487591190000@Atlassian.JIRA>
References: <JIRA.12677747.1487591190000@Atlassian.JIRA>
	<JIRA.12677747.1487591190164@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677747.1487591190000.47467.1487591220193@Atlassian.JIRA>

Hayk Hovsepyan created HAWKULARQE-43:
----------------------------------------

             Summary: Hawkular Agent for EAP 6.4
                 Key: HAWKULARQE-43
                 URL: https://issues.jboss.org/browse/HAWKULARQE-43
             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 Feb 20 06:48:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 06:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4
In-Reply-To: <JIRA.12677747.1487591190000@Atlassian.JIRA>
References: <JIRA.12677747.1487591190000@Atlassian.JIRA>
	<JIRA.12677747.1487591190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677747.1487591190000.47476.1487591281251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-43:
-------------------------------------
    Description: Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP6%20Server%20Smoke%20Tests%20Template


> Hawkular Agent for EAP 6.4
> --------------------------
>
>                 Key: HAWKULARQE-43
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-43
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP6%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 06:53:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 20 Feb 2017 06:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.47525.1487591580407@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366069#comment-13366069 ] 

Ingo Weiss commented on WFLY-8141:
----------------------------------

Hi [~brian.stansberry], then 1) would transform CCM into a regular node which, I believe, wasn't the original intention. Wouldn't it be better, in that case, to return the add op and make it an noop?

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 07:30:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 07:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8165) Missing log that
 authetication failed in Elytron LdapRealm
In-Reply-To: <JIRA.12677760.1487593771000@Atlassian.JIRA>
References: <JIRA.12677760.1487593771000@Atlassian.JIRA>
	<JIRA.12677760.1487593771426@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677760.1487593771000.47781.1487593801186@Atlassian.JIRA>

Ondrej Lukas created WFLY-8165:
----------------------------------

             Summary: Missing log that authetication failed in Elytron LdapRealm
                 Key: WFLY-8165
                 URL: https://issues.jboss.org/browse/WFLY-8165
             Project: WildFly
          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  Mon Feb 20 07:34:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 20 Feb 2017 07:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.47825.1487594040251@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366094#comment-13366094 ] 

Martin Choma commented on ELY-969:
----------------------------------

Cool!

But it seems to me moving key password(s) into KeyStore, makes key-manager resource more pointless. As key-manager is in real used only 1 (however array is prepared), could be IMO moved into key-store resource (with only valid attribute algorithm). 
 

> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 07:38:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 07:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-969) Add a KeyStore implementation
 that can use the key store password for retrieving entries.
In-Reply-To: <JIRA.12677574.1487348114000@Atlassian.JIRA>
References: <JIRA.12677574.1487348114000@Atlassian.JIRA>
	<JIRA.12677574.1487348114000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677574.1487348114000.47897.1487594280450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366098#comment-13366098 ] 

Darran Lofthouse commented on ELY-969:
--------------------------------------

No a key-store resource needs to return a KeyStore instance, it can't return a KeyManager instance.  Some resources do make use of the raw KeyStore.

> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
>                 Key: ELY-969
>                 URL: https://issues.jboss.org/browse/ELY-969
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: KeyStores
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 07:47:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Mon, 20 Feb 2017 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8166) The enable-elytron.cli script
 doesn't change configuration of messaging subsystem
In-Reply-To: <JIRA.12677762.1487594813000@Atlassian.JIRA>
References: <JIRA.12677762.1487594813000@Atlassian.JIRA>
	<JIRA.12677762.1487594813582@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677762.1487594813000.47943.1487594820646@Atlassian.JIRA>

Josef Cacek created WFLY-8166:
---------------------------------

             Summary: The enable-elytron.cli script doesn't change configuration of messaging subsystem
                 Key: WFLY-8166
                 URL: https://issues.jboss.org/browse/WFLY-8166
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Josef Cacek


Reconfiguration of the {{standalone-full.xml}} profile in {{testsuite/shared/enable-elytron.cli}} should change the messaging subsystem configuration too.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 07:55:00 2017
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Mon, 20 Feb 2017 07:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-33) [QE] - JMAN4-188 - Secure
 link from CloudForms to MW Provider
In-Reply-To: <JIRA.12676682.1487083547000@Atlassian.JIRA>
References: <JIRA.12676682.1487083547000@Atlassian.JIRA>
	<JIRA.12676682.1487083547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676682.1487083547000.48149.1487595300391@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vojtech Prusa reassigned HAWKULARQE-33:
---------------------------------------

    Assignee: Vojtech Prusa  (was: mfoley user)


> [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
>
> 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  Mon Feb 20 07:59:00 2017
From: issues at jboss.org (Biswajit Bhuyan (JIRA))
Date: Mon, 20 Feb 2017 07:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2158) NPE from
	org.apache.log4j.CategoryKey.
In-Reply-To: <JIRA.12677792.1487595517000@Atlassian.JIRA>
References: <JIRA.12677792.1487595517000@Atlassian.JIRA>
	<JIRA.12677792.1487595517329@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677792.1487595517000.48202.1487595540185@Atlassian.JIRA>

Biswajit Bhuyan created JGRP-2158:
-------------------------------------

             Summary: NPE from org.apache.log4j.CategoryKey.
                 Key: JGRP-2158
                 URL: https://issues.jboss.org/browse/JGRP-2158
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.6.11
            Reporter: Biswajit Bhuyan
            Assignee: Bela Ban


Getting NPE from jGroup. Please find the stacktrace below:
java.lang.NullPointerException
	at org.apache.log4j.CategoryKey.<init>(CategoryKey.java:32)
	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:266)
	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:247)
	at org.apache.log4j.LogManager.getLogger(LogManager.java:228)
	at org.apache.log4j.Logger.getLogger(Logger.java:104)
	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.getTargetLogger(Debug.java:1798)
	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.publish(Debug.java:1790)
	at java.util.logging.Logger.log(Logger.java:738)
	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:49)
	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:28)
	at org.jgroups.logging.JDKLogImpl.warn(JDKLogImpl.java:122)
	at org.jgroups.stack.Configurator.setDefaultValues(Configurator.java:754)
	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:117)
	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476)
	at org.jgroups.JChannel.init(JChannel.java:852)
	at org.jgroups.JChannel.<init>(JChannel.java:159)
	at org.jgroups.JChannel.<init>(JChannel.java:148)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:04:00 2017
From: issues at jboss.org (Arkady Syamtomov (JIRA))
Date: Mon, 20 Feb 2017 08:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1383) Deadlock in
	PackageClassLoader
In-Reply-To: <JIRA.12668005.1481886901000@Atlassian.JIRA>
References: <JIRA.12668005.1481886901000@Atlassian.JIRA>
	<JIRA.12668005.1481886901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668005.1481886901000.48229.1487595840279@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366130#comment-13366130 ] 

Arkady Syamtomov commented on DROOLS-1383:
------------------------------------------

We had the same issue with continuous Class.forName() calls inside the ProjectClassLoader. If manifested itself especially blocking when we developed the parallel deployment of rules (we have amounts like 15 000 and more). More investigation showed the locks happen on continuous Class.forName invocations in fastFindClass and down to call stack. And the reason was that despite the Class.forName throws NoClassFoundException (e.g. for queries inside the rule) the ClassLoader continues doing it again and again (instead of storing the invalid strings in some kind of blacklist). We patched locally the ProjectClassLoader with the one  you'll find in attachment - that boosted the performance by approx 60 times in our case. Please have a look and maybe similar modifications could be applied on your side (of course there are some name-specific fragments, but I'm sure more generic solution could be found). 

> Deadlock in PackageClassLoader
> ------------------------------
>
>                 Key: DROOLS-1383
>                 URL: https://issues.jboss.org/browse/DROOLS-1383
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Karen Zhu
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> Found one deadlock in PackageLoader. Did I write rule in a bad way? How did a consequence of a rule will get the lock of PackageLoader which is needed by checkCerts(). Below is threaddump information.
> Found one Java-level deadlock:
> =============================
> "Thread-105-CustomClass-executor[17 17]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> "Thread-17-CustomClass-executor[33 33]":
> waiting to lock monitor 0x00007f933c0031f8 (object 0x00007f963ed294c0, a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader),
> which is held by "Thread-33-CustomClass-executor[9 9]"
> "Thread-33-CustomClass-executor[9 9]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-105-CustomClass-executor[17 17]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-17-CustomClass-executor[33 33]":
> at java.lang.ClassLoader.checkCerts(ClassLoader.java:942)
> waiting to lock <0x00007f963ed294c0> (a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader)
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:666)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.internalDefineClass(JavaDialectRuntimeData.java:694)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:665)
> locked <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-33-CustomClass-executor[9 9]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at com.cdr.apEventWrapperRules.ConstructorApBeansWrapper.constructorApBeansWrapper(ConstructorApBeansWrapper.java:55)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097.defaultConsequence(Rule_UCR2359988097.java:7)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1089)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> 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.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> Found 1 deadlock.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:05:00 2017
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Mon, 20 Feb 2017 08:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-34) Automation Testcase
In-Reply-To: <JIRA.12676683.1487083606000@Atlassian.JIRA>
References: <JIRA.12676683.1487083606000@Atlassian.JIRA>
	<JIRA.12676683.1487083606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676683.1487083606000.48237.1487595900514@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vojtech Prusa reassigned HAWKULARQE-34:
---------------------------------------

    Assignee: Vojtech Prusa  (was: mfoley user)


> Automation Testcase
> -------------------
>
>                 Key: HAWKULARQE-34
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-34
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Vojtech Prusa
>            Priority: Critical
>
> Smoke automation test to add new middleware provider with SSL and check that inventory is loaded.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:05:00 2017
From: issues at jboss.org (Arkady Syamtomov (JIRA))
Date: Mon, 20 Feb 2017 08:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1383) Deadlock in
	PackageClassLoader
In-Reply-To: <JIRA.12668005.1481886901000@Atlassian.JIRA>
References: <JIRA.12668005.1481886901000@Atlassian.JIRA>
	<JIRA.12668005.1481886901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668005.1481886901000.48241.1487595900609@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arkady Syamtomov updated DROOLS-1383:
-------------------------------------
    Attachment: ProjectClassLoader.java


> Deadlock in PackageClassLoader
> ------------------------------
>
>                 Key: DROOLS-1383
>                 URL: https://issues.jboss.org/browse/DROOLS-1383
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Karen Zhu
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: ProjectClassLoader.java
>
>
> Found one deadlock in PackageLoader. Did I write rule in a bad way? How did a consequence of a rule will get the lock of PackageLoader which is needed by checkCerts(). Below is threaddump information.
> Found one Java-level deadlock:
> =============================
> "Thread-105-CustomClass-executor[17 17]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> "Thread-17-CustomClass-executor[33 33]":
> waiting to lock monitor 0x00007f933c0031f8 (object 0x00007f963ed294c0, a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader),
> which is held by "Thread-33-CustomClass-executor[9 9]"
> "Thread-33-CustomClass-executor[9 9]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-105-CustomClass-executor[17 17]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-17-CustomClass-executor[33 33]":
> at java.lang.ClassLoader.checkCerts(ClassLoader.java:942)
> waiting to lock <0x00007f963ed294c0> (a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader)
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:666)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.internalDefineClass(JavaDialectRuntimeData.java:694)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:665)
> locked <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-33-CustomClass-executor[9 9]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at com.cdr.apEventWrapperRules.ConstructorApBeansWrapper.constructorApBeansWrapper(ConstructorApBeansWrapper.java:55)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097.defaultConsequence(Rule_UCR2359988097.java:7)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1089)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> 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.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> Found 1 deadlock.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:11:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 20 Feb 2017 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8151) Unable to create custom
 credentail security factory
In-Reply-To: <JIRA.12677441.1487311688000@Atlassian.JIRA>
References: <JIRA.12677441.1487311688000@Atlassian.JIRA>
	<JIRA.12677441.1487311688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677441.1487311688000.48267.1487596260419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFLY-8151:
----------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Darran Lofthouse)


> Unable to create custom credentail security factory
> ---------------------------------------------------
>
>                 Key: WFLY-8151
>                 URL: https://issues.jboss.org/browse/WFLY-8151
>             Project: WildFly
>          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<T> implements CredentialSecurityFactory, Configurable {
>     @Override
>     public Credential create() throws GeneralSecurityException {
>         return null;
>     }
>     @Override
>     public void initialize(Map<String, String> 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  Mon Feb 20 08:13:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 20 Feb 2017 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579055000@Atlassian.JIRA>
References: <JIRA.12677693.1487579055000@Atlassian.JIRA>
	<JIRA.12677693.1487579055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579055000.48301.1487596380822@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366136#comment-13366136 ] 

Matteo Mortari commented on DROOLS-1445:
----------------------------------------

+ additionally, as discussed, similar possibly-connected problem on the test {{org.drools.compiler.integrationtests.AccumulateTest.testAccFunctionOpaqueJoins}}

When running as original and PropertyReactivity == ALWAYS, the test FAIL and the rete is:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [LeftInputAdapterNode(10)] on Partition(3) Ld 0 Li 0
            [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(13): rule=M] on Partition(3) d -1 i -1
            [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(15): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(11)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
        [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
{code}

While adding a constraints as {{Tick( tick != null, $index : tick ) }} inside rule M and J would result in the following rete:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [AlphaNode(10) constraint=tick != null] on Partition(3) d 2 i 2
            [LeftInputAdapterNode(11)] on Partition(3) Ld 0 Li 0
                [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(14): rule=M] on Partition(3) d -1 i -1
                [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(16): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(12)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
        [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
{code}

beside the additional alpha node, kindly notice the AccumulateNode are having the Left Inferred mask correctly populated.

> Mask should reflect properties accessed in other nodes join constraints
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1445
>                 URL: https://issues.jboss.org/browse/DROOLS-1445
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>
> The following test exhibit a failing and a working test:
> {code:java}
>     @Test()
>     public void testAbis_NotWorking() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "    $p2 : Person( age > $p1.age ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         ksession.addEventListener(new DebugAgendaEventListener());
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
>     
>     @Test()
>     public void testAbis_Working() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
>                 "    $p2 : Person( age > $a1 ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:13:01 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 20 Feb 2017 08:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579055000@Atlassian.JIRA>
References: <JIRA.12677693.1487579055000@Atlassian.JIRA>
	<JIRA.12677693.1487579055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579055000.48313.1487596381184@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366136#comment-13366136 ] 

Matteo Mortari edited comment on DROOLS-1445 at 2/20/17 8:12 AM:
-----------------------------------------------------------------

+ additionally, as discussed, similar possibly-connected problem on the test {{org.drools.compiler.integrationtests.AccumulateTest.testAccFunctionOpaqueJoins}}

When running as original and PropertyReactivity == ALWAYS, the test FAIL and the rete is:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [LeftInputAdapterNode(10)] on Partition(3) Ld 0 Li 0
            [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(13): rule=M] on Partition(3) d -1 i -1
            [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(15): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(11)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
        [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
{code}

While adding a constraints as {{ Tick( tick != null, $index : tick ) }} inside rule M and J would result in the following rete:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [AlphaNode(10) constraint=tick != null] on Partition(3) d 2 i 2
            [LeftInputAdapterNode(11)] on Partition(3) Ld 0 Li 0
                [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(14): rule=M] on Partition(3) d -1 i -1
                [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(16): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(12)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
        [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
{code}

beside the additional alpha node, kindly notice the AccumulateNode are having the Left Inferred mask correctly populated.


was (Author: tari_manga):
+ additionally, as discussed, similar possibly-connected problem on the test {{org.drools.compiler.integrationtests.AccumulateTest.testAccFunctionOpaqueJoins}}

When running as original and PropertyReactivity == ALWAYS, the test FAIL and the rete is:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [LeftInputAdapterNode(10)] on Partition(3) Ld 0 Li 0
            [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(13): rule=M] on Partition(3) d -1 i -1
            [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
                [RuleTerminalNode(15): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(11)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(12) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
        [ AccumulateNode(14) ] on Partition(3) Ld 0 Li 0 Rd 2 Ri 2
{code}

While adding a constraints as {{Tick( tick != null, $index : tick ) }} inside rule M and J would result in the following rete:

{code:java}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(7)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Tick] expiration=-1ms ] on Partition(MAIN)
        [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
            [RuleTerminalNode(9): rule=Update] on Partition(2) d -1 i -1
        [AlphaNode(10) constraint=tick != null] on Partition(3) d 2 i 2
            [LeftInputAdapterNode(11)] on Partition(3) Ld 0 Li 0
                [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(14): rule=M] on Partition(3) d -1 i -1
                [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
                    [RuleTerminalNode(16): rule=J] on Partition(3) d -1 i -1
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(3)] on Partition(1) Ld 0 Li 0
            [RuleTerminalNode(4): rule=Init] on Partition(1) d -1 i -1
    [ObjectTypeNode(5)::EntryPoint::DEFAULT objectType=[ClassObjectType class=java.lang.Integer] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(6)] on Partition(2) Ld 0 Li 0
            [JoinNode(8) - [ClassObjectType class=org.test.Tick]] on Partition(2) Ld -1 Li -1 Rd 0 Ri 0
    [ObjectTypeNode(12)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.test.Data] expiration=-1ms ] on Partition(MAIN)
        [ AccumulateNode(13) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
        [ AccumulateNode(15) ] on Partition(3) Ld 0 Li 2 Rd 2 Ri 2
{code}

beside the additional alpha node, kindly notice the AccumulateNode are having the Left Inferred mask correctly populated.

> Mask should reflect properties accessed in other nodes join constraints
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1445
>                 URL: https://issues.jboss.org/browse/DROOLS-1445
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>
> The following test exhibit a failing and a working test:
> {code:java}
>     @Test()
>     public void testAbis_NotWorking() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "    $p2 : Person( age > $p1.age ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         ksession.addEventListener(new DebugAgendaEventListener());
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
>     
>     @Test()
>     public void testAbis_Working() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
>                 "    $p2 : Person( age > $a1 ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:22:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 20 Feb 2017 08:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579055000@Atlassian.JIRA>
References: <JIRA.12677693.1487579055000@Atlassian.JIRA>
	<JIRA.12677693.1487579055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579055000.48493.1487596920126@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366153#comment-13366153 ] 

Matteo Mortari commented on DROOLS-1445:
----------------------------------------

All the Property Reactive changes are currently here: https://github.com/tarilabs/drools/tree/eo-propreactivedefault

> Mask should reflect properties accessed in other nodes join constraints
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1445
>                 URL: https://issues.jboss.org/browse/DROOLS-1445
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>
> The following test exhibit a failing and a working test:
> {code:java}
>     @Test()
>     public void testAbis_NotWorking() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "    $p2 : Person( age > $p1.age ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         ksession.addEventListener(new DebugAgendaEventListener());
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
>     
>     @Test()
>     public void testAbis_Working() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
>                 "    $p2 : Person( age > $a1 ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 08:40:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1443) Improve effect of caching
 in ChainedProperties.
In-Reply-To: <JIRA.12676988.1487168226000@Atlassian.JIRA>
References: <JIRA.12676988.1487168226000@Atlassian.JIRA>
	<JIRA.12676988.1487168226000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676988.1487168226000.48641.1487598000634@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1443.
---------------------------------
    Fix Version/s: 7.0.0.CR1
       Resolution: Done


Fixed by https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/0dc50245159ba7113bd8938dd64264448298c08c and https://github.com/droolsjbpm/drools/commit/d61a86f216e4d58ee80c39b5de3b97177476ddb2

> Improve effect of caching in ChainedProperties.  
> -------------------------------------------------
>
>                 Key: DROOLS-1443
>                 URL: https://issues.jboss.org/browse/DROOLS-1443
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>            Reporter: Hans Lund
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 7.0.0.CR1
>
>
> The ChainedProperties utility has a caching setting that will cache the classpath discovery of property resource - but not the parsing of these resources.
> This utility is a hot spot for the initialization of runtime environments - caching the parsed properties instead of the resource url will improve runtime performance.
> Changing the caching strategy will make hot changes to classpath property resources impossible. File based property files could be made safe cacheable by investigating file metadata and only read if changed.     



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:02:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Mon, 20 Feb 2017 09:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment
In-Reply-To: <JIRA.12677335.1487269804000@Atlassian.JIRA>
References: <JIRA.12677335.1487269804000@Atlassian.JIRA>
	<JIRA.12677335.1487269804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677335.1487269804000.48884.1487599320562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prachi Yadav reassigned HAWKULARQE-37:
--------------------------------------

    Assignee: Prachi Yadav  (was: mfoley user)


> 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 Feb 20 09:03:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 09:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-40) XA Datasource creation
In-Reply-To: <JIRA.12677338.1487269932000@Atlassian.JIRA>
References: <JIRA.12677338.1487269932000@Atlassian.JIRA>
	<JIRA.12677338.1487269932000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677338.1487269932000.48885.1487599380058@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-40:
-------------------------------------
    Description: 
Manual testcases.
Automation testcases.

BZ should be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1383611

  was:
Manual testcases.
Automation testcases.



> 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 Feb 20 09:04:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 09:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.48896.1487599440387@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-41:
-------------------------------------
    Description: 
Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template

Bug should be fixed https://bugzilla.redhat.com/show_bug.cgi?id=1370499

  was:Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



> Hawkular Agent for EAP7.1
> -------------------------
>
>                 Key: HAWKULARQE-41
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: mfoley user
>
> Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template
> Bug should be fixed https://bugzilla.redhat.com/show_bug.cgi?id=1370499



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:21:01 2017
From: issues at jboss.org (Sunil kondkar (JIRA))
Date: Mon, 20 Feb 2017 09:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated
 on failed operations
In-Reply-To: <JIRA.12677830.1487600438000@Atlassian.JIRA>
References: <JIRA.12677830.1487600438000@Atlassian.JIRA>
	<JIRA.12677830.1487600438478@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677830.1487600438000.49220.1487600461857@Atlassian.JIRA>

Sunil kondkar created HAWKULARQE-44:
---------------------------------------

             Summary: 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: mfoley user


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:
Re-verify blocked test cases and mark the status in polarion



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:28:01 2017
From: issues at jboss.org (Markus Wahl (JIRA))
Date: Mon, 20 Feb 2017 09:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8158) JSP source code leak when
 space and periods added at the end of the URL
In-Reply-To: <JIRA.12677510.1487332335000@Atlassian.JIRA>
References: <JIRA.12677510.1487332335000@Atlassian.JIRA>
	<JIRA.12677510.1487332335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677510.1487332335000.49427.1487600881437@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366242#comment-13366242 ] 

Markus Wahl commented on WFLY-8158:
-----------------------------------

Great. I will look into that commit. Thanks [~swd847]

BTW why can't we study the JIRA UNDERTOW-576 (or UNDERTOW-432 for that matter)? I received a response from a Vlastimil Elias (software engineer, jboss.org Development Team) who said it was because of a security issue. But since everything is readily accessibly via the public git-hib-repository I believe that response to not have much merit. Please, what is your opinion? Is it possible to change that policy so that we can inspect all JIRA-issues for undertow?


> JSP source code leak when space and periods added at the end of the URL
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8158
>                 URL: https://issues.jboss.org/browse/WFLY-8158
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.2.0.Final
>         Environment: WildFly executing on Windows
>            Reporter: Markus Wahl
>            Assignee: Stuart Douglas
>            Priority: Blocker
>
> All of the following requests will return the jsp file content untransformed, meaning that the actual content of the jsp-file is returned to the browser.
> {code}
> http://localhost:8080/application/HostPage.jsp%2E
> http://localhost:8080/application/HostPage.jsp%2E%2E
> http://localhost:8080/application/HostPage.jsp%20%2E
> http://localhost:8080/application/HostPage.jsp%20%2E%2E
> {code}
> The problem with periods has perhaps to do with windows removing/accepting trailing periods in file names: [here|http://stackoverflow.com/questions/17746494/why-is-directory-name-which-contains-dots-in-the-end-is-treated-as-a-directory], [and here|http://stackoverflow.com/questions/11681207/how-to-create-a-filename-with-a-trailing-period-in-windows/16203594#16203594] because {{io.undertow.server.handlers.resource.FileResourceManager.getResource()}} delegates to {{java.io.File}} to test whether a file path is valid or not, and {{java.io.File}} does presumably delegate to Windows.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:42:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8167) Properties of Elytron
 dir-context are parsed incorrectly
In-Reply-To: <JIRA.12677876.1487601677000@Atlassian.JIRA>
References: <JIRA.12677876.1487601677000@Atlassian.JIRA>
	<JIRA.12677876.1487601677595@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677876.1487601677000.49766.1487601720438@Atlassian.JIRA>

Ondrej Lukas created WFLY-8167:
----------------------------------

             Summary: Properties of Elytron dir-context are parsed incorrectly
                 Key: WFLY-8167
                 URL: https://issues.jboss.org/browse/WFLY-8167
             Project: WildFly
          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  Mon Feb 20 09:44:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Feb 2017 09:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2158) NPE from
	org.apache.log4j.CategoryKey.
In-Reply-To: <JIRA.12677792.1487595517000@Atlassian.JIRA>
References: <JIRA.12677792.1487595517000@Atlassian.JIRA>
	<JIRA.12677792.1487595517000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677792.1487595517000.49797.1487601840880@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366289#comment-13366289 ] 

Bela Ban commented on JGRP-2158:
--------------------------------

The NPE is not from JGroups but from log4j; please investigate there.

> NPE from org.apache.log4j.CategoryKey.
> --------------------------------------
>
>                 Key: JGRP-2158
>                 URL: https://issues.jboss.org/browse/JGRP-2158
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.11
>            Reporter: Biswajit Bhuyan
>            Assignee: Bela Ban
>
> Getting NPE from jGroup. Please find the stacktrace below:
> java.lang.NullPointerException
> 	at org.apache.log4j.CategoryKey.<init>(CategoryKey.java:32)
> 	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:266)
> 	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:247)
> 	at org.apache.log4j.LogManager.getLogger(LogManager.java:228)
> 	at org.apache.log4j.Logger.getLogger(Logger.java:104)
> 	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.getTargetLogger(Debug.java:1798)
> 	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.publish(Debug.java:1790)
> 	at java.util.logging.Logger.log(Logger.java:738)
> 	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:49)
> 	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:28)
> 	at org.jgroups.logging.JDKLogImpl.warn(JDKLogImpl.java:122)
> 	at org.jgroups.stack.Configurator.setDefaultValues(Configurator.java:754)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:117)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476)
> 	at org.jgroups.JChannel.init(JChannel.java:852)
> 	at org.jgroups.JChannel.<init>(JChannel.java:159)
> 	at org.jgroups.JChannel.<init>(JChannel.java:148)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:45:02 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 20 Feb 2017 09:45:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2158) NPE from
	org.apache.log4j.CategoryKey.
In-Reply-To: <JIRA.12677792.1487595517000@Atlassian.JIRA>
References: <JIRA.12677792.1487595517000@Atlassian.JIRA>
	<JIRA.12677792.1487595517000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677792.1487595517000.49836.1487601902583@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban closed JGRP-2158.
--------------------------
    Resolution: Rejected


Not a JGroups problem

> NPE from org.apache.log4j.CategoryKey.
> --------------------------------------
>
>                 Key: JGRP-2158
>                 URL: https://issues.jboss.org/browse/JGRP-2158
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.6.11
>            Reporter: Biswajit Bhuyan
>            Assignee: Bela Ban
>
> Getting NPE from jGroup. Please find the stacktrace below:
> java.lang.NullPointerException
> 	at org.apache.log4j.CategoryKey.<init>(CategoryKey.java:32)
> 	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:266)
> 	at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:247)
> 	at org.apache.log4j.LogManager.getLogger(LogManager.java:228)
> 	at org.apache.log4j.Logger.getLogger(Logger.java:104)
> 	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.getTargetLogger(Debug.java:1798)
> 	at com.webmethods.rtl.util.Debug$JuliToLog4jHandler.publish(Debug.java:1790)
> 	at java.util.logging.Logger.log(Logger.java:738)
> 	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:49)
> 	at org.jgroups.logging.JDKLogImpl.log(JDKLogImpl.java:28)
> 	at org.jgroups.logging.JDKLogImpl.warn(JDKLogImpl.java:122)
> 	at org.jgroups.stack.Configurator.setDefaultValues(Configurator.java:754)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:117)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476)
> 	at org.jgroups.JChannel.init(JChannel.java:852)
> 	at org.jgroups.JChannel.<init>(JChannel.java:159)
> 	at org.jgroups.JChannel.<init>(JChannel.java:148)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:48:02 2017
From: issues at jboss.org (Sunil kondkar (JIRA))
Date: Mon, 20 Feb 2017 09:48:02 -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: <JIRA.12677885.1487602065000@Atlassian.JIRA>
References: <JIRA.12677885.1487602065000@Atlassian.JIRA>
	<JIRA.12677885.1487602065263@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677885.1487602065000.49938.1487602082491@Atlassian.JIRA>

Sunil kondkar created HAWKULARQE-45:
---------------------------------------

             Summary: 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: mfoley user


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 Feb 20 09:53:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 20 Feb 2017 09:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-971) LdapRealm - referral mode:
 direct verification + FOLLOW mode
In-Reply-To: <JIRA.12677893.1487602363000@Atlassian.JIRA>
References: <JIRA.12677893.1487602363000@Atlassian.JIRA>
	<JIRA.12677893.1487602363752@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677893.1487602363000.49987.1487602380613@Atlassian.JIRA>

Jan Kalina created ELY-971:
------------------------------

             Summary: LdapRealm - referral mode: direct verification + FOLLOW  mode
                 Key: ELY-971
                 URL: https://issues.jboss.org/browse/ELY-971
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Critical






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:55:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 20 Feb 2017 09:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-971) LdapRealm - referral mode:
 direct verification + FOLLOW mode
In-Reply-To: <JIRA.12677893.1487602364000@Atlassian.JIRA>
References: <JIRA.12677893.1487602364000@Atlassian.JIRA>
	<JIRA.12677893.1487602364000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677893.1487602364000.50000.1487602500458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-971:
---------------------------
    Description: The same problem as ELY-804 but in FOLLOW mode of DirContext.


> LdapRealm - referral mode: direct verification + FOLLOW  mode
> -------------------------------------------------------------
>
>                 Key: ELY-971
>                 URL: https://issues.jboss.org/browse/ELY-971
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Realms
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> The same problem as ELY-804 but in FOLLOW mode of DirContext.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 09:59:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 20 Feb 2017 09:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4
In-Reply-To: <JIRA.12677747.1487591190000@Atlassian.JIRA>
References: <JIRA.12677747.1487591190000@Atlassian.JIRA>
	<JIRA.12677747.1487591190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677747.1487591190000.50062.1487602741498@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366319#comment-13366319 ] 

Hayk Hovsepyan commented on HAWKULARQE-43:
------------------------------------------

Depends on BZ https://bugzilla.redhat.com/show_bug.cgi?id=1384949

> Hawkular Agent for EAP 6.4
> --------------------------
>
>                 Key: HAWKULARQE-43
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-43
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP6%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 10:04:00 2017
From: issues at jboss.org (Sunil kondkar (JIRA))
Date: Mon, 20 Feb 2017 10:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated
 on failed operations
In-Reply-To: <JIRA.12677830.1487600438000@Atlassian.JIRA>
References: <JIRA.12677830.1487600438000@Atlassian.JIRA>
	<JIRA.12677830.1487600438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677830.1487600438000.50155.1487603040636@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sunil kondkar updated HAWKULARQE-44:
------------------------------------
    Description: 
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


  was:
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:
Re-verify blocked test cases and mark the status in polarion



> 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: mfoley user
>
> 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  Mon Feb 20 10:21:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Mon, 20 Feb 2017 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated
 on failed operations
In-Reply-To: <JIRA.12677830.1487600438000@Atlassian.JIRA>
References: <JIRA.12677830.1487600438000@Atlassian.JIRA>
	<JIRA.12677830.1487600438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677830.1487600438000.50386.1487604060346@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prachi Yadav reassigned HAWKULARQE-44:
--------------------------------------

    Assignee: Prachi Yadav  (was: mfoley user)


> 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  Mon Feb 20 10:29:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 20 Feb 2017 10:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604495000@Atlassian.JIRA>
References: <JIRA.12677931.1487604495000@Atlassian.JIRA>
	<JIRA.12677931.1487604495514@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604495000.50453.1487604540345@Atlassian.JIRA>

Jan Tymel created ELY-972:
-----------------------------

             Summary: Elytron Audit Logging does not log failed authentication
                 Key: ELY-972
                 URL: https://issues.jboss.org/browse/ELY-972
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Jan Tymel
            Assignee: Darran Lofthouse
            Priority: Blocker


Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.

Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 10:29:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Mon, 20 Feb 2017 10:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.50458.1487604540498@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reassigned ELY-972:
-----------------------------

    Assignee:     (was: Darran Lofthouse)


> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 10:33:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1383) Deadlock in
	PackageClassLoader
In-Reply-To: <JIRA.12668005.1481886901000@Atlassian.JIRA>
References: <JIRA.12668005.1481886901000@Atlassian.JIRA>
	<JIRA.12668005.1481886901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668005.1481886901000.50482.1487604780290@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366357#comment-13366357 ] 

Mario Fusco commented on DROOLS-1383:
-------------------------------------

We already have a blacklist for unknown classes https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/core/common/ProjectClassLoader.java#L49

What you did in your modified ProjectClassLoader version is adding a second cache that is static and then shared by all the ProjectClassLoder instances. This is not acceptable because a class that doesn't exist in a given project could conversely be present in a second project running on the same JVM.

> Deadlock in PackageClassLoader
> ------------------------------
>
>                 Key: DROOLS-1383
>                 URL: https://issues.jboss.org/browse/DROOLS-1383
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Karen Zhu
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: ProjectClassLoader.java
>
>
> Found one deadlock in PackageLoader. Did I write rule in a bad way? How did a consequence of a rule will get the lock of PackageLoader which is needed by checkCerts(). Below is threaddump information.
> Found one Java-level deadlock:
> =============================
> "Thread-105-CustomClass-executor[17 17]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> "Thread-17-CustomClass-executor[33 33]":
> waiting to lock monitor 0x00007f933c0031f8 (object 0x00007f963ed294c0, a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader),
> which is held by "Thread-33-CustomClass-executor[9 9]"
> "Thread-33-CustomClass-executor[9 9]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-105-CustomClass-executor[17 17]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-17-CustomClass-executor[33 33]":
> at java.lang.ClassLoader.checkCerts(ClassLoader.java:942)
> waiting to lock <0x00007f963ed294c0> (a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader)
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:666)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.internalDefineClass(JavaDialectRuntimeData.java:694)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:665)
> locked <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-33-CustomClass-executor[9 9]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at com.cdr.apEventWrapperRules.ConstructorApBeansWrapper.constructorApBeansWrapper(ConstructorApBeansWrapper.java:55)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097.defaultConsequence(Rule_UCR2359988097.java:7)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1089)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> 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.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> Found 1 deadlock.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 10:37:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 10:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2309) Regression in EAP
 7.1.0.DR12: username-load attribute of legacy LDAP Realm stop to work
In-Reply-To: <JIRA.12677935.1487604992000@Atlassian.JIRA>
References: <JIRA.12677935.1487604992000@Atlassian.JIRA>
	<JIRA.12677935.1487604992009@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677935.1487604992000.50528.1487605020496@Atlassian.JIRA>

Ondrej Lukas created WFCORE-2309:
------------------------------------

             Summary: Regression in EAP 7.1.0.DR12: 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


{{username-load}} attribute of legacy LDAP Realm stop to work in EAP 7.1.0.DR12. This attribute is used for assigning username from some LDAP entry attribute. In current behavior in EAP 7.1.0.DR12 it seems that it tries to search user in LDAP through value obtained from entry 'username-load' attribute. See mentioned below logs for more details.

Due to regression we request blocker. Taking EAP 7.0.x configuration and put it into EAP 7.1.x will causes that username-load feature stop to work.

Despite username-load attribute of legacy LDAP Realm was fixed in EAP 7.1.0.DR11 (JBEAP-7821) it has been broken again in EAP 7.1.0.DR12.

Server log for DR12:
{code}
2017-02-20 16:17:22,440 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:17:22,441 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:17:22,441 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:17:22,442 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:17:22,474 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:17:22,474 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest9c88e710,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:17:22,475 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'Duke'
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'Duke' using filter '(uid={0})'.
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:17:22,482 TRACE [org.jboss.as.domain.management.security] (management task-6) User 'Duke' not found in directory.
{code}

Server log for DR11:
{code}
2017-02-20 16:23:33,269 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,303 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,303 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:23:33,304 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,309 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,309 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:23:33,310 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,317 TRACE [org.jboss.as.domain.management.security] (management task-6) Password verified for user 'jduke' (using connection attempt)
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,325 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,326 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 10:39:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 10:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2309) Regression in EAP
 7.1.0.DR12: username-load attribute of legacy LDAP Realm stop to work
In-Reply-To: <JIRA.12677935.1487604992000@Atlassian.JIRA>
References: <JIRA.12677935.1487604992000@Atlassian.JIRA>
	<JIRA.12677935.1487604992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677935.1487604992000.50566.1487605140507@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFCORE-2309:
---------------------------------
           Description: 
{{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.





  was:
{{username-load}} attribute of legacy LDAP Realm stop to work in EAP 7.1.0.DR12. This attribute is used for assigning username from some LDAP entry attribute. In current behavior in EAP 7.1.0.DR12 it seems that it tries to search user in LDAP through value obtained from entry 'username-load' attribute. See mentioned below logs for more details.

Due to regression we request blocker. Taking EAP 7.0.x configuration and put it into EAP 7.1.x will causes that username-load feature stop to work.

Despite username-load attribute of legacy LDAP Realm was fixed in EAP 7.1.0.DR11 (JBEAP-7821) it has been broken again in EAP 7.1.0.DR12.

Server log for DR12:
{code}
2017-02-20 16:17:22,440 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:17:22,441 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:17:22,441 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:17:22,442 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:17:22,474 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:17:22,474 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest9c88e710,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:17:22,475 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'Duke'
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'Duke' using filter '(uid={0})'.
2017-02-20 16:17:22,476 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:17:22,482 TRACE [org.jboss.as.domain.management.security] (management task-6) User 'Duke' not found in directory.
{code}

Server log for DR11:
{code}
2017-02-20 16:23:33,269 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,270 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,303 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,303 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:23:33,304 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,305 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,309 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,309 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
2017-02-20 16:23:33,310 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,317 TRACE [org.jboss.as.domain.management.security] (management task-6) Password verified for user 'jduke' (using connection attempt)
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Non caching search for 'jduke'
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Performing single level search
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Searching for user 'jduke' using filter '(uid={0})'.
2017-02-20 16:23:33,318 TRACE [org.jboss.as.domain.management.security] (management task-6) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
2017-02-20 16:23:33,325 TRACE [org.jboss.as.domain.management.security] (management task-6) Converted username 'jduke' to 'Duke'
2017-02-20 16:23:33,326 TRACE [org.jboss.as.domain.management.security] (management task-6) DN 'uid=jduke,ou=People,o=LdapRealmUsernameLoadOptionManualTest10fe60be,o=primary,dc=jboss,dc=org' found for user 'Duke'
{code}

    Steps to Reproduce: Use the same reproducer as WFCORE-2161  (was: Use the same reproducer as JBEAP-7821)


> Regression in EAP 7.1.0.DR12: 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
>
> {{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  Mon Feb 20 10:44:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 20 Feb 2017 10:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2309) username-load attribute of
 legacy LDAP Realm stop to work
In-Reply-To: <JIRA.12677935.1487604992000@Atlassian.JIRA>
References: <JIRA.12677935.1487604992000@Atlassian.JIRA>
	<JIRA.12677935.1487604992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677935.1487604992000.50609.1487605440273@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFCORE-2309:
---------------------------------
    Summary: username-load attribute of legacy LDAP Realm stop to work  (was: Regression in EAP 7.1.0.DR12: username-load attribute of legacy LDAP Realm stop to work)


> 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
>
> {{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  Mon Feb 20 11:26:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 20 Feb 2017 11:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.50937.1487607960216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-972:
------------------------------

    Assignee: Jan Kalina


> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 11:34:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 20 Feb 2017 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8152) Elytron,
 unable to create custom principal transformer
In-Reply-To: <JIRA.12677443.1487313137000@Atlassian.JIRA>
References: <JIRA.12677443.1487313137000@Atlassian.JIRA>
	<JIRA.12677443.1487313137000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677443.1487313137000.50993.1487608440873@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-8152:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> Elytron, unable to create custom principal transformer
> ------------------------------------------------------
>
>                 Key: WFLY-8152
>                 URL: https://issues.jboss.org/browse/WFLY-8152
>             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<String, String> 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  Mon Feb 20 11:40:01 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Feb 2017 11:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1085) No audit feature for
	security-realm
In-Reply-To: <JIRA.12485608.1361840867000@Atlassian.JIRA>
References: <JIRA.12485608.1361840867000@Atlassian.JIRA>
	<JIRA.12485608.1361840867000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485608.1361840867000.51050.1487608801113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366410#comment-13366410 ] 

RH Bugzilla Integration commented on WFLY-1085:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 912233|https://bugzilla.redhat.com/show_bug.cgi?id=912233] from ASSIGNED to CLOSED

> No audit feature for security-realm
> -----------------------------------
>
>                 Key: WFLY-1085
>                 URL: https://issues.jboss.org/browse/WFLY-1085
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>         Environment: EAP 6.0.x
>            Reporter: Hisanobu Okuda
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> There is no auditing feature for security-realm. Need the feature like audit provider for security-domain.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 12:10:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 12:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1446) Implement RuleUnit
In-Reply-To: <JIRA.12677953.1487610557000@Atlassian.JIRA>
References: <JIRA.12677953.1487610557000@Atlassian.JIRA>
	<JIRA.12677953.1487610557691@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677953.1487610557000.51286.1487610600185@Atlassian.JIRA>

Mario Fusco created DROOLS-1446:
-----------------------------------

             Summary: Implement RuleUnit
                 Key: DROOLS-1446
                 URL: https://issues.jboss.org/browse/DROOLS-1446
             Project: Drools
          Issue Type: Feature Request
            Reporter: Mario Fusco
            Assignee: Edson Tirelli






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 12:10:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 12:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1446) Implement RuleUnit
In-Reply-To: <JIRA.12677953.1487610558000@Atlassian.JIRA>
References: <JIRA.12677953.1487610558000@Atlassian.JIRA>
	<JIRA.12677953.1487610558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677953.1487610558000.51289.1487610600251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-1446:
-----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Implement RuleUnit
> ------------------
>
>                 Key: DROOLS-1446
>                 URL: https://issues.jboss.org/browse/DROOLS-1446
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 12:10:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 20 Feb 2017 12:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1446) Implement RuleUnit
In-Reply-To: <JIRA.12677953.1487610558000@Atlassian.JIRA>
References: <JIRA.12677953.1487610558000@Atlassian.JIRA>
	<JIRA.12677953.1487610558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677953.1487610558000.51291.1487610600296@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-1446:
--------------------------------
    Component/s: core engine


> Implement RuleUnit
> ------------------
>
>                 Key: DROOLS-1446
>                 URL: https://issues.jboss.org/browse/DROOLS-1446
>             Project: Drools
>          Issue Type: Feature Request
>          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  Mon Feb 20 13:40:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 13:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.51615.1487616000707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-8141:
--------------------------------------

    Assignee: Brian Stansberry  (was: Ingo Weiss)


> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 13:40:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 13:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.51609.1487616000467@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366471#comment-13366471 ] 

Brian Stansberry commented on WFLY-8141:
----------------------------------------

Scratch my #1 and #2 above. I think these are the requirements around this:

1) If a user *boots* a config with subsystem=jca in it but nothing that specifies CCM use, they should be able to go to the CLI and do this:

[standalone at localhost:9999 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=install,value=true)

That should work even though their config didn't specify anything to trigger adding the /subsystem=jca/cached-connection-manager=cached-connection-manage resource.

This needs to work to be compatible with previous behavior, not because it's good.

2) Users starts a standalone server or  domain profile with no JCA subsystem and then can do this:

/profile=default-web/subsystem="jca":add()
/profile=default-web/subsystem="jca"/cached-connection-manager="cached-connection-manager":add()

(For the standalone server case ignore the /profile=default-web part).

This needs to work or we have a regression. That's the main point of this JIRA. Fixing this will also fix Alexey's problem.

3) We want the WFY-2640 scenario to work:

a) boot with JCA subsystem present
b) With CLI:

{code}
[standalone at localhost:9990 /] /subsystem=jca/cached-connection-manager=cached-connection-manager: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 /] /subsystem=jca/cached-connection-manager=cached-connection-manager:add
{
    "outcome" => "success",
    "result" => undefined
}
{code}

The only way I see to meet all these objectives is to make the add handler public again, and rewrite it to not fail if the resource is already present, but is configured with all default values (i.e. interpret that state as meaning the resource was auto-added by the parser). The resource must always be present after boot for 1) to work. The add op must be public for 2). And for 3) to work in combination with 1), the add handler can't reject the add just because the parser already auto-added the resource.

Having the following work is NOT a requirement:

a) start with no JCA
b) With CLI

/subsystem="jca":add()
/subsystem="jca"/cached-connection-manager="cached-connection-manager":write-attribute(name=install,value=true)

It's the parser that "auto-adds" the CCM resource, allowing you to do a write-attribute to the CCM. Here there is no parser involved so you have to add it before you can write-attribute.

Making the above work would be possible via the step adding tricks I mentioned in my last post. But it's not really valid behavior and in a mixed version domain the legacy slaves wouldn't be able to handle it. So I don't think we should do it. Instead we should regard 1) working as being a bug, but one that we aren't fixing because fixing it might break people.

[~maeste] Without objection I like to go ahead and implement it this way.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Ingo Weiss
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 13:41:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 13:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2310) Upgrade WildFly Client
 Config to 1.0.0.Beta2
In-Reply-To: <JIRA.12677962.1487616007000@Atlassian.JIRA>
References: <JIRA.12677962.1487616007000@Atlassian.JIRA>
	<JIRA.12677962.1487616007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677962.1487616007000.51630.1487616060462@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved JBEAP-8973 to WFCORE-2310:
-------------------------------------------------

     Project: WildFly Core  (was: JBoss Enterprise Application Platform)
         Key: WFCORE-2310  (was: JBEAP-8973)
    Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)


> Upgrade WildFly Client Config to 1.0.0.Beta2
> --------------------------------------------
>
>                 Key: WFCORE-2310
>                 URL: https://issues.jboss.org/browse/WFCORE-2310
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Darran Lofthouse
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 13:42:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 13:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2311) System property
 wildfly.config.url doesn't resolve correctly relative paths
In-Reply-To: <JIRA.12673894.1485866354000@Atlassian.JIRA>
References: <JIRA.12673894.1485866354000@Atlassian.JIRA>
	<JIRA.12673894.1485866354000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673894.1485866354000.51637.1487616120334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-8001 to WFCORE-2311:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2311  (was: WFLY-8001)
    Component/s: Security
                     (was: Security)


> 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 Feb 20 14:27:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 14:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-973) Add configuration option for
 DigestSaslServer to support additional protocols
In-Reply-To: <JIRA.12677967.1487618819000@Atlassian.JIRA>
References: <JIRA.12677967.1487618819000@Atlassian.JIRA>
	<JIRA.12677967.1487618819107@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677967.1487618819000.51743.1487618820163@Atlassian.JIRA>

Darran Lofthouse created ELY-973:
------------------------------------

             Summary: Add configuration option for DigestSaslServer to support additional protocols
                 Key: ELY-973
                 URL: https://issues.jboss.org/browse/ELY-973
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: SASL
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta28


Older clients may attempt to authenticate using both remote and remoting as the protocol.  Add a configuration option to specify additional protocols that can be accepted.





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 14:35:00 2017
From: issues at jboss.org (Daniel Huss (JIRA))
Date: Mon, 20 Feb 2017 14:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8168) Inter-application depdendency
 injection failure
In-Reply-To: <JIRA.12677968.1487619280000@Atlassian.JIRA>
References: <JIRA.12677968.1487619280000@Atlassian.JIRA>
	<JIRA.12677968.1487619280136@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677968.1487619280000.51753.1487619300494@Atlassian.JIRA>

Daniel Huss created WFLY-8168:
---------------------------------

             Summary: Inter-application depdendency injection failure
                 Key: WFLY-8168
                 URL: https://issues.jboss.org/browse/WFLY-8168
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 10.1.0.Final
            Reporter: Daniel Huss
            Assignee: Stuart Douglas
         Attachments: inter-app-dependency.zip

I was trying to implement a simple use case:

* There's some service.ear providing a _Service_
* service.ear has a module alias _ModuleAlias_
* There are add-ons to _Service _that are dynamically deployed as jar files that depend on _ModuleAlias_ via manifest entries
* The add-ons register/unregister themselves with _Service_ on deployment/undeployment

The [CDI Reference|https://docs.jboss.org/author/display/WFLY10/CDI+Reference] states that we can depend on other deployments, so this seemed to be the easiest way to get the job done with JEE.

The registration-on-deployment thing would look like this: 
{code}
   public void register(@Observes @Initialized(ApplicationScoped.class) Object init, AddonContext context)
    {
        context.register(this);
    }
{code}

All I get is "WELD-001408: Unsatisfied dependencies". 

So I've created a minimalistic example of the inter-app dependency scenario. See attachment. I've tried moving around module-alias, CDI annotations.... it just won't work.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 14:35:00 2017
From: issues at jboss.org (Daniel Huss (JIRA))
Date: Mon, 20 Feb 2017 14:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8168) Inter-application depdendency
 injection failure
In-Reply-To: <JIRA.12677968.1487619280000@Atlassian.JIRA>
References: <JIRA.12677968.1487619280000@Atlassian.JIRA>
	<JIRA.12677968.1487619280000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677968.1487619280000.51756.1487619300585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Huss updated WFLY-8168:
------------------------------
    Attachment: inter-app-dependency.zip


> Inter-application depdendency injection failure
> -----------------------------------------------
>
>                 Key: WFLY-8168
>                 URL: https://issues.jboss.org/browse/WFLY-8168
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.1.0.Final
>            Reporter: Daniel Huss
>            Assignee: Stuart Douglas
>         Attachments: inter-app-dependency.zip
>
>
> I was trying to implement a simple use case:
> * There's some service.ear providing a _Service_
> * service.ear has a module alias _ModuleAlias_
> * There are add-ons to _Service _that are dynamically deployed as jar files that depend on _ModuleAlias_ via manifest entries
> * The add-ons register/unregister themselves with _Service_ on deployment/undeployment
> The [CDI Reference|https://docs.jboss.org/author/display/WFLY10/CDI+Reference] states that we can depend on other deployments, so this seemed to be the easiest way to get the job done with JEE.
> The registration-on-deployment thing would look like this: 
> {code}
>    public void register(@Observes @Initialized(ApplicationScoped.class) Object init, AddonContext context)
>     {
>         context.register(this);
>     }
> {code}
> All I get is "WELD-001408: Unsatisfied dependencies". 
> So I've created a minimalistic example of the inter-app dependency scenario. See attachment. I've tried moving around module-alias, CDI annotations.... it just won't work.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 14:41:00 2017
From: issues at jboss.org (Arkady Syamtomov (JIRA))
Date: Mon, 20 Feb 2017 14:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1383) Deadlock in
	PackageClassLoader
In-Reply-To: <JIRA.12668005.1481886901000@Atlassian.JIRA>
References: <JIRA.12668005.1481886901000@Atlassian.JIRA>
	<JIRA.12668005.1481886901000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668005.1481886901000.51777.1487619660290@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366502#comment-13366502 ] 

Arkady Syamtomov commented on DROOLS-1383:
------------------------------------------

Thanks fir that prompt reply!
the class I attached was just for demo purposes - to outline the points we found as responsible for mutual thread locking. About the blacklisted classes and resources I preferred to leave the existing set alone, firstly it's not thread safe anyways, secondly - did not want to introduce additional implications to the existing code. Whatsoever these "blacklist" sets were to address quite specific issues with existing code - skip multiple Class.forName or ClassLoader.getResource calls for the same key. I'm not even sure we do now really need those - they were introduced as a first attempt to find solution. 

I completely agree with your comment about static maps and sets members, but these are just to indicate that we do need a kind of cache scoping. Whether it's a JVM, thread, or project - does not matter. But when running the building in multiple threads we need to make sure we don't block threads trying to access Class.forName at the same time - these calls are heavyweight and synchronised.  

One of key points in the code for us is attempt to skip the names, that are not classes - and these really massively influence the performance as causing a huge amount of calls, resulting in ClassNotFoundException. In our case the pattern is simple (any string ending with "_query"), but in general any kind of configuration would suffice (the default behaviour could remain unaltered). Any kind of ProjectClassLoader extension mechanism would work (e.g. standard java lookup service)... At the moment it's not simply possible to substitute it with any inheriting class. Would it be possible for you to consider these changes for future release or as a patch to existing one?  Thank you a lot!

> Deadlock in PackageClassLoader
> ------------------------------
>
>                 Key: DROOLS-1383
>                 URL: https://issues.jboss.org/browse/DROOLS-1383
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.4.0.Final
>            Reporter: Karen Zhu
>            Assignee: Mario Fusco
>            Priority: Blocker
>         Attachments: ProjectClassLoader.java
>
>
> Found one deadlock in PackageLoader. Did I write rule in a bad way? How did a consequence of a rule will get the lock of PackageLoader which is needed by checkCerts(). Below is threaddump information.
> Found one Java-level deadlock:
> =============================
> "Thread-105-CustomClass-executor[17 17]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> "Thread-17-CustomClass-executor[33 33]":
> waiting to lock monitor 0x00007f933c0031f8 (object 0x00007f963ed294c0, a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader),
> which is held by "Thread-33-CustomClass-executor[9 9]"
> "Thread-33-CustomClass-executor[9 9]":
> waiting to lock monitor 0x00007f933c005b38 (object 0x00007f963ed294b0, a java.lang.Object),
> which is held by "Thread-17-CustomClass-executor[33 33]"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-105-CustomClass-executor[17 17]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-17-CustomClass-executor[33 33]":
> at java.lang.ClassLoader.checkCerts(ClassLoader.java:942)
> waiting to lock <0x00007f963ed294c0> (a org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader)
> at java.lang.ClassLoader.preDefineClass(ClassLoader.java:666)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:794)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.internalDefineClass(JavaDialectRuntimeData.java:694)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:665)
> locked <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at org.drools.core.rule.MVELDialectRuntimeData.getParserConfiguration(MVELDialectRuntimeData.java:299)
> at org.drools.core.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
> at org.drools.core.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:264)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:366)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> "Thread-33-CustomClass-executor[9 9]":
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:662)
> waiting to lock <0x00007f963ed294b0> (a java.lang.Object)
> at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:642)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at com.cdr.apEventWrapperRules.ConstructorApBeansWrapper.constructorApBeansWrapper(ConstructorApBeansWrapper.java:55)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097.defaultConsequence(Rule_UCR2359988097.java:7)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> at com.cdr.apEventWrapperRules.Rule_UCR2359988097DefaultConsequenceInvoker.evaluate(Unknown Source)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1089)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> 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.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> Found 1 deadlock.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 14:59:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 20 Feb 2017 14:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.51868.1487620740556@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366506#comment-13366506 ] 

Darran Lofthouse commented on ELY-972:
--------------------------------------

There may be a few things to think about this one.

Although some mechanisms use evidence verification many don't - we may want to look at the AuthenticationCompleteCallback carrying a message that can be used here.

Also the HTTP mechanisms call the CallbackHandler but also need to call authenticationFailed on the request - as the mechanisms already report their outcome we may want to automate the call to the CBH so the mech doesn't need to perform two notifications.



> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 17:26:00 2017
From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=)
Date: Mon, 20 Feb 2017 17:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1447) Runtime exception when
 validating a file with empy name
In-Reply-To: <JIRA.12677980.1487629528000@Atlassian.JIRA>
References: <JIRA.12677980.1487629528000@Atlassian.JIRA>
	<JIRA.12677980.1487629528028@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677980.1487629528000.52470.1487629560161@Atlassian.JIRA>

M?lanie Gauthier created DROOLS-1447:
----------------------------------------

             Summary: Runtime exception when validating a file with empy name
                 Key: DROOLS-1447
                 URL: https://issues.jboss.org/browse/DROOLS-1447
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: M?lanie Gauthier
            Assignee: Edson Tirelli
         Attachments: NoName1.dmn

When a variable has an empty name, the validation throws a runtime exeception as follow:

Caused by: java.lang.RuntimeException: Error evaluating constraint 'FEELParser.isVariableNameValid( name ) == false' in [Rule "NAME_INVALID" in rules.drl]
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:262)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:215)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:316)
	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:152)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:157)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:93)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:88)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1055)
	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1018)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1010)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1292)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1283)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1267)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:282)
	at org.kie.dmn.validation.DMNValidatorImpl.validateModel(DMNValidatorImpl.java:145)
	at com.trisotech.dmn.redhat.transformation.DMN1ValidationTransformation.internalTransform(DMN1ValidationTransformation.java:64)
	at com.trisotech.transformation.engine.transformation.AbstractTransformation.transform(AbstractTransformation.java:86)
	... 42 more
Caused by: java.lang.NullPointerException
	at org.kie.dmn.feel.parser.feel11.ParserHelper.getOriginalText(ParserHelper.java:150)
	at org.kie.dmn.feel.parser.feel11.ParserHelper.defineVariable(ParserHelper.java:125)
	at org.kie.dmn.feel.parser.feel11.FEEL_1_1Parser.nameDefinition(FEEL_1_1Parser.java:1459)
	at org.kie.dmn.feel.parser.feel11.FEELParser.isVariableNameValid(FEELParser.java:59)
	at ConditionEvaluator59c2efa132a0438abcc40f9d4d01d964.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:260)
	... 60 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 17:27:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Feb 2017 17:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1447) Runtime exception when
 validating a file with empy name
In-Reply-To: <JIRA.12677980.1487629528000@Atlassian.JIRA>
References: <JIRA.12677980.1487629528000@Atlassian.JIRA>
	<JIRA.12677980.1487629528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677980.1487629528000.52473.1487629620328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-1447:
----------------------------------
        Fix Version/s: 7.0.0.Final
    Affects Version/s: 7.0.0.Beta6


> Runtime exception when validating a file with empy name
> -------------------------------------------------------
>
>                 Key: DROOLS-1447
>                 URL: https://issues.jboss.org/browse/DROOLS-1447
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: M?lanie Gauthier
>            Assignee: Edson Tirelli
>             Fix For: 7.0.0.Final
>
>         Attachments: NoName1.dmn
>
>
> When a variable has an empty name, the validation throws a runtime exeception as follow:
> Caused by: java.lang.RuntimeException: Error evaluating constraint 'FEELParser.isVariableNameValid( name ) == false' in [Rule "NAME_INVALID" in rules.drl]
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:262)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:215)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:316)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:152)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:157)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:88)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1055)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1018)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1010)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1292)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1283)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1267)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:282)
> 	at org.kie.dmn.validation.DMNValidatorImpl.validateModel(DMNValidatorImpl.java:145)
> 	at com.trisotech.dmn.redhat.transformation.DMN1ValidationTransformation.internalTransform(DMN1ValidationTransformation.java:64)
> 	at com.trisotech.transformation.engine.transformation.AbstractTransformation.transform(AbstractTransformation.java:86)
> 	... 42 more
> Caused by: java.lang.NullPointerException
> 	at org.kie.dmn.feel.parser.feel11.ParserHelper.getOriginalText(ParserHelper.java:150)
> 	at org.kie.dmn.feel.parser.feel11.ParserHelper.defineVariable(ParserHelper.java:125)
> 	at org.kie.dmn.feel.parser.feel11.FEEL_1_1Parser.nameDefinition(FEEL_1_1Parser.java:1459)
> 	at org.kie.dmn.feel.parser.feel11.FEELParser.isVariableNameValid(FEELParser.java:59)
> 	at ConditionEvaluator59c2efa132a0438abcc40f9d4d01d964.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:260)
> 	... 60 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 17:29:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 20 Feb 2017 17:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1447) Runtime exception when
 validating a file with empy name
In-Reply-To: <JIRA.12677980.1487629528000@Atlassian.JIRA>
References: <JIRA.12677980.1487629528000@Atlassian.JIRA>
	<JIRA.12677980.1487629528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677980.1487629528000.52488.1487629740378@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-1447:
-------------------------------------

    Assignee: Matteo Mortari  (was: Edson Tirelli)


> Runtime exception when validating a file with empy name
> -------------------------------------------------------
>
>                 Key: DROOLS-1447
>                 URL: https://issues.jboss.org/browse/DROOLS-1447
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.0.0.Beta6
>            Reporter: M?lanie Gauthier
>            Assignee: Matteo Mortari
>             Fix For: 7.0.0.Final
>
>         Attachments: NoName1.dmn
>
>
> When a variable has an empty name, the validation throws a runtime exeception as follow:
> Caused by: java.lang.RuntimeException: Error evaluating constraint 'FEELParser.isVariableNameValid( name ) == false' in [Rule "NAME_INVALID" in rules.drl]
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:262)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:215)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:316)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:152)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:157)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:93)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:88)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1055)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1018)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1010)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1292)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1283)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1267)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:282)
> 	at org.kie.dmn.validation.DMNValidatorImpl.validateModel(DMNValidatorImpl.java:145)
> 	at com.trisotech.dmn.redhat.transformation.DMN1ValidationTransformation.internalTransform(DMN1ValidationTransformation.java:64)
> 	at com.trisotech.transformation.engine.transformation.AbstractTransformation.transform(AbstractTransformation.java:86)
> 	... 42 more
> Caused by: java.lang.NullPointerException
> 	at org.kie.dmn.feel.parser.feel11.ParserHelper.getOriginalText(ParserHelper.java:150)
> 	at org.kie.dmn.feel.parser.feel11.ParserHelper.defineVariable(ParserHelper.java:125)
> 	at org.kie.dmn.feel.parser.feel11.FEEL_1_1Parser.nameDefinition(FEEL_1_1Parser.java:1459)
> 	at org.kie.dmn.feel.parser.feel11.FEELParser.isVariableNameValid(FEELParser.java:59)
> 	at ConditionEvaluator59c2efa132a0438abcc40f9d4d01d964.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:260)
> 	... 60 more



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 18:22:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 18:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2312) Management console won't
 load if master host in domain is unsecured
In-Reply-To: <JIRA.12677987.1487632855000@Atlassian.JIRA>
References: <JIRA.12677987.1487632855000@Atlassian.JIRA>
	<JIRA.12677987.1487632855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677987.1487632855000.52693.1487632920797@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2312:
-------------------------------------
    Fix Version/s: 3.0.0.Beta4


> Management console won't load if master host in domain is unsecured
> -------------------------------------------------------------------
>
>                 Key: WFCORE-2312
>                 URL: https://issues.jboss.org/browse/WFCORE-2312
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Beta2
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta4
>
>
> When domain master host is unsecured, management console won't load in domain mode. This is regression against 7.1.0.DR11 and 7.0.0.GA.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 18:22:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 18:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2312) Management console won't
 load if master host in domain is unsecured
In-Reply-To: <JIRA.12677987.1487632855000@Atlassian.JIRA>
References: <JIRA.12677987.1487632855000@Atlassian.JIRA>
	<JIRA.12677987.1487632855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677987.1487632855000.52686.1487632920533@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-8974 to WFCORE-2312:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2312  (was: JBEAP-8974)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                       Security
                           (was: Domain Management)
                           (was: Security)
    Affects Version/s: 3.0.0.Beta2
                           (was: 7.1.0.DR12)
      Affects Testing:   (was: Regression,Blocks Testing)


> Management console won't load if master host in domain is unsecured
> -------------------------------------------------------------------
>
>                 Key: WFCORE-2312
>                 URL: https://issues.jboss.org/browse/WFCORE-2312
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Beta2
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta4
>
>
> When domain master host is unsecured, management console won't load in domain mode. This is regression against 7.1.0.DR11 and 7.0.0.GA.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 18:23:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 18:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2312) Management console won't
 load if master host in domain is unsecured
In-Reply-To: <JIRA.12677987.1487632855000@Atlassian.JIRA>
References: <JIRA.12677987.1487632855000@Atlassian.JIRA>
	<JIRA.12677987.1487632855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677987.1487632855000.52700.1487632980398@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2312:
-------------------------------------
    Steps to Reproduce: 
# Unsecure WildFly {{sed "s/http-interface security-realm=\"ManagementRealm\"/http-interface/g" -i "$WILDFLY_HOME/domain/configuration/host.xml"}}
# Start WF in domain mode
# Try to access web console

  was:
# Unsecure EAP {{sed "s/http-interface security-realm=\"ManagementRealm\"/http-interface/g" -i "$EAP_HOME/domain/configuration/host.xml"}}
# Start EAP in domain mode
# Try to access web console



> Management console won't load if master host in domain is unsecured
> -------------------------------------------------------------------
>
>                 Key: WFCORE-2312
>                 URL: https://issues.jboss.org/browse/WFCORE-2312
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Beta2
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta4
>
>
> When domain master host is unsecured, management console won't load in domain mode. This is regression against 7.1.0.DR11 and 7.0.0.GA.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 18:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 18:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2312) Management console won't
 load if master host in domain is unsecured
In-Reply-To: <JIRA.12677987.1487632855000@Atlassian.JIRA>
References: <JIRA.12677987.1487632855000@Atlassian.JIRA>
	<JIRA.12677987.1487632855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677987.1487632855000.52725.1487633640346@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366579#comment-13366579 ] 

Brian Stansberry commented on WFCORE-2312:
------------------------------------------

Problem is IdentityAddressProtocolUtil.read:

{code}
        ProtocolUtils.expectHeader(input, ITEMS_PARAM);
        final int itemCount = input.readInt();

        Principal principal = null;
        Set<String> roles = new HashSet<>(itemCount - 2);
{code}

There is no guarantee that itemCount is >= 2.

> Management console won't load if master host in domain is unsecured
> -------------------------------------------------------------------
>
>                 Key: WFCORE-2312
>                 URL: https://issues.jboss.org/browse/WFCORE-2312
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Beta2
>            Reporter: Jan Ka??k
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta4
>
>
> When domain master host is unsecured, management console won't load in domain mode. This is regression against 7.1.0.DR11 and 7.0.0.GA.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 20 19:57:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 20 Feb 2017 19:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-655) Customizable Console Log
	Viewer
In-Reply-To: <JIRA.12568491.1429106324000@Atlassian.JIRA>
References: <JIRA.12568491.1429106324000@Atlassian.JIRA>
	<JIRA.12568491.1429106324000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568491.1429106324000.52821.1487638620234@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366590#comment-13366590 ] 

RH Bugzilla Integration commented on WFCORE-655:
------------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1212078|https://bugzilla.redhat.com/show_bug.cgi?id=1212078] from ASSIGNED to CLOSED

> Customizable Console Log Viewer
> -------------------------------
>
>                 Key: WFCORE-655
>                 URL: https://issues.jboss.org/browse/WFCORE-655
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: Carlton Zachary
>            Assignee: James Perkins
>            Priority: Optional
>
> Currently the Console log viewer only points to jboss.server.log.dir.  In our Domain environment we have our server.log write to a non-default location.  This is defined in the host-slave.xml as:
> <paths>
>          <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/>
> </paths>
> it is then referenced in the domain.xml file logging subsystem as:
> <file relative-to="custom.jboss.server.log.dir" path="server.log"/>
> Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location?
> https://bugzilla.redhat.com/show_bug.cgi?id=1191180
> Thanks



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 20:31:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 20:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8169) attributes of BYTES unit
 should not allow negative values
In-Reply-To: <JIRA.12663919.1480315634000@Atlassian.JIRA>
References: <JIRA.12663919.1480315634000@Atlassian.JIRA>
	<JIRA.12663919.1480315634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663919.1480315634000.52980.1487640660409@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFCORE-2048 to WFLY-8169:
------------------------------------------------

        Project: WildFly  (was: WildFly Core)
            Key: WFLY-8169  (was: WFCORE-2048)
    Component/s: Web (Undertow)
                     (was: Domain Management)


> attributes of BYTES unit should not allow negative values
> ---------------------------------------------------------
>
>                 Key: WFLY-8169
>                 URL: https://issues.jboss.org/browse/WFLY-8169
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> 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}
> As unit of these attributes is used {{BYTES}} we should not allow user to input negative numbers there. Currently I can simply put negative number and server does not protest anyhow (I guess that server simply interpret given negative number as actual unsigned number of integer internally?). We should inform user that we expect only positive numbers for these attributes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 20:31:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 20:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8169) attributes of BYTES unit
 should not allow negative values
In-Reply-To: <JIRA.12663919.1480315634000@Atlassian.JIRA>
References: <JIRA.12663919.1480315634000@Atlassian.JIRA>
	<JIRA.12663919.1480315634000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663919.1480315634000.52985.1487640660541@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366593#comment-13366593 ] 

Brian Stansberry commented on WFLY-8169:
----------------------------------------

I've moved this from core and changed the component as this isn't about kernel behavior, it's about the configuration of a particular set of attributes.

> attributes of BYTES unit should not allow negative values
> ---------------------------------------------------------
>
>                 Key: WFLY-8169
>                 URL: https://issues.jboss.org/browse/WFLY-8169
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> 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}
> As unit of these attributes is used {{BYTES}} we should not allow user to input negative numbers there. Currently I can simply put negative number and server does not protest anyhow (I guess that server simply interpret given negative number as actual unsigned number of integer internally?). We should inform user that we expect only positive numbers for these attributes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 20:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 20:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2180) Server shutdown
 intermittently gets stuck when SSL is used for native-interface
In-Reply-To: <JIRA.12670323.1484135994000@Atlassian.JIRA>
References: <JIRA.12670323.1484135994000@Atlassian.JIRA>
	<JIRA.12670323.1484135994000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12670323.1484135994000.53023.1487642280532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2180:
----------------------------------------

    Assignee: Ken Wills  (was: Brian Stansberry)


> Server shutdown intermittently gets stuck when SSL is used for native-interface
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-2180
>                 URL: https://issues.jboss.org/browse/WFCORE-2180
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Ondrej Lukas
>            Assignee: Ken Wills
>            Priority: Blocker
>
> In case when SSL is used for native-interface and at least one call is made for that interface (e.g. through Management CLI) then shutdown of application server intermittently gets stuck. Then application server process cannot be killed through simple {{kill}} command, {{kill -9}} has to be used. It happens for legacy SSL as well as Elytron SSL. It get stuck ~ 3 times from 10 shutdowns. See Step for Reproduce for more details.
> We reported as blocker since:
> * application server is intermittently not able to be stopped
> * it is regression between EAP 7.0.0.GA and EAP 7.1.0
> Output of jstack for application server process after it gets stuck during shutdown:
> {code}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.66-b17 mixed mode):
> "Attach Listener" #128 daemon prio=9 os_prio=0 tid=0x00007ff710001800 nid=0x173e waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Thread-2" #11 prio=5 os_prio=0 tid=0x00007ff74c1ee800 nid=0x1711 waiting on condition [0x00007ff6b47ba000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f68311d0> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.shutdown(BootstrapImpl.java:267)
> 	at org.jboss.as.server.BootstrapImpl$ShutdownHook.run(BootstrapImpl.java:236)
> "SIGINT handler" #127 daemon prio=9 os_prio=0 tid=0x00007ff710003800 nid=0x170e in Object.wait() [0x00007ff6b4abd000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000fa15d390> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> 	at java.lang.Thread.join(Thread.java:1245)
> 	- locked <0x00000000fa15d390> (a org.jboss.as.server.BootstrapImpl$ShutdownHook)
> 	at java.lang.Thread.join(Thread.java:1319)
> 	at java.lang.ApplicationShutdownHooks.runHooks(ApplicationShutdownHooks.java:106)
> 	at java.lang.ApplicationShutdownHooks$1.run(ApplicationShutdownHooks.java:46)
> 	at java.lang.Shutdown.runHooks(Shutdown.java:123)
> 	at java.lang.Shutdown.sequence(Shutdown.java:167)
> 	at java.lang.Shutdown.exit(Shutdown.java:212)
> 	- locked <0x00000000f9ea39e0> (a java.lang.Class for java.lang.Shutdown)
> 	at java.lang.Terminator$1.handle(Terminator.java:52)
> 	at sun.misc.Signal$1.run(Signal.java:212)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-9" #126 prio=5 os_prio=0 tid=0x00007ff74c1ea000 nid=0x1709 waiting on condition [0x00007ff6b4bbe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-8" #125 prio=5 os_prio=0 tid=0x00007ff74c2e2000 nid=0x1707 waiting on condition [0x00007ff6b4cbf000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-7" #123 prio=5 os_prio=0 tid=0x00007ff74c2e0000 nid=0x1704 waiting on condition [0x00007ff6b4ec1000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-6" #121 prio=5 os_prio=0 tid=0x00007ff74c2de800 nid=0x1701 waiting on condition [0x00007ff6b50c3000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-5" #119 prio=5 os_prio=0 tid=0x00007ff74c2dd000 nid=0x16fe waiting on condition [0x00007ff6b52c5000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-4" #117 prio=5 os_prio=0 tid=0x00007ff74c248800 nid=0x16fb waiting on condition [0x00007ff6b54c7000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-3" #116 prio=5 os_prio=0 tid=0x00007ff74c24b000 nid=0x16fa waiting on condition [0x00007ff6b55c8000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-2" #115 prio=5 os_prio=0 tid=0x00007ff74c243000 nid=0x16f8 waiting on condition [0x00007ff6b58c9000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "management task-1" #114 prio=5 os_prio=0 tid=0x00007ff74c242000 nid=0x16f6 waiting on condition [0x00007ff72db0c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000ead164a0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "SecurityDomain ThreadGroup - 1" #113 prio=5 os_prio=0 tid=0x00007ff74c24c000 nid=0x16f5 waiting on condition [0x00007ff6b5ccd000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f16ba540> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "Transaction Reaper Worker 0" #105 daemon prio=5 os_prio=0 tid=0x00007ff6e01a6000 nid=0x16d0 in Object.wait() [0x00007ff6b6bc3000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000ec155598> (a java.util.LinkedList)
> 	at java.lang.Object.wait(Object.java:502)
> 	at com.arjuna.ats.arjuna.coordinator.TransactionReaper.waitForCancellations(TransactionReaper.java:328)
> 	- locked <0x00000000ec155598> (a java.util.LinkedList)
> 	at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:65)
> "Transaction Reaper" #104 daemon prio=5 os_prio=0 tid=0x00007ff6e01a5000 nid=0x16cf in Object.wait() [0x00007ff6b6cc4000]
>    java.lang.Thread.State: TIMED_WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000ec151eb0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> 	at com.arjuna.ats.internal.arjuna.coordinator.ReaperThread.run(ReaperThread.java:90)
> 	- locked <0x00000000ec151eb0> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
> "Remoting (anonymous) Accept" #78 daemon prio=5 os_prio=0 tid=0x00007ff6e4100800 nid=0x16bc runnable [0x00007ff6bcaaf000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x00000000eb009578> (a sun.nio.ch.Util$2)
> 	- locked <0x00000000eb009568> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x00000000eb009450> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) I/O-1" #73 daemon prio=5 os_prio=0 tid=0x00007ff6e40fd800 nid=0x16bb runnable [0x00007ff6bcbb0000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x00000000eaff89e0> (a sun.nio.ch.Util$2)
> 	- locked <0x00000000eaff89d0> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x00000000eaff88b8> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management Accept" #60 prio=5 os_prio=0 tid=0x00007ff6e80d1000 nid=0x16a5 runnable [0x00007ff6be3c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x00000000ead46cd8> (a sun.nio.ch.Util$2)
> 	- locked <0x00000000ead46cc8> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x00000000ead46bb0> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-2" #59 prio=5 os_prio=0 tid=0x00007ff6e80cf800 nid=0x16a4 runnable [0x00007ff6be4c7000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x00000000ead361a0> (a sun.nio.ch.Util$2)
> 	- locked <0x00000000ead36190> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x00000000ead36078> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-1" #57 prio=5 os_prio=0 tid=0x00007ff6e80cd800 nid=0x16a3 runnable [0x00007ff6be5c8000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0x00000000ead253c8> (a sun.nio.ch.Util$2)
> 	- locked <0x00000000ead253b8> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0x00000000ead252a0> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "DestroyJavaVM" #23 prio=5 os_prio=0 tid=0x00007ff74c00b000 nid=0x1667 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "ServerDeploymentRepository-temp-threads - 1" #21 daemon prio=5 os_prio=0 tid=0x00007ff6fc01c000 nid=0x167f waiting on condition [0x00007ff72e00d000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9990eb8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "MSC service thread 1-8" #20 prio=5 os_prio=0 tid=0x00007ff6e0003000 nid=0x167e waiting on condition [0x00007ff72e10e000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-7" #19 prio=5 os_prio=0 tid=0x00007ff6e0001000 nid=0x167d waiting on condition [0x00007ff72e20f000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-6" #18 prio=5 os_prio=0 tid=0x00007ff6ec001000 nid=0x167c waiting on condition [0x00007ff72e310000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-5" #17 prio=5 os_prio=0 tid=0x00007ff74c8c2000 nid=0x167b waiting on condition [0x00007ff72e411000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-4" #16 prio=5 os_prio=0 tid=0x00007ff6f4001800 nid=0x167a waiting on condition [0x00007ff72e512000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-3" #15 prio=5 os_prio=0 tid=0x00007ff6f0001800 nid=0x1679 waiting on condition [0x00007ff72e613000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-2" #14 prio=5 os_prio=0 tid=0x00007ff6fc002000 nid=0x1678 waiting on condition [0x00007ff72e714000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 1-1" #13 prio=5 os_prio=0 tid=0x00007ff74c870000 nid=0x1677 waiting on condition [0x00007ff72e815000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000000f9991660> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "Reference Reaper" #9 daemon prio=5 os_prio=0 tid=0x00007ff74c26a800 nid=0x1675 in Object.wait() [0x00007ff72fefd000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000f9659788> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0x00000000f9659788> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at org.jboss.modules.ref.References$ReaperThread.run(References.java:64)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007ff74c194000 nid=0x1673 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007ff74c186800 nid=0x1672 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007ff74c184800 nid=0x1671 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007ff74c182000 nid=0x1670 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007ff74c180000 nid=0x166f runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007ff74c147800 nid=0x166e in Object.wait() [0x00007ff734d34000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000f9a81078> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0x00000000f9a81078> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007ff74c145800 nid=0x166d in Object.wait() [0x00007ff734e35000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000000f9a81290> (a java.lang.ref.Reference$Lock)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
> 	- locked <0x00000000f9a81290> (a java.lang.ref.Reference$Lock)
> "VM Thread" os_prio=0 tid=0x00007ff74c140800 nid=0x166c runnable 
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007ff74c020800 nid=0x1668 runnable 
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007ff74c022000 nid=0x1669 runnable 
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007ff74c024000 nid=0x166a runnable 
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007ff74c025800 nid=0x166b runnable 
> "VM Periodic Task Thread" os_prio=0 tid=0x00007ff74c197000 nid=0x1674 waiting on condition 
> JNI global references: 1251
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 20:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 20:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7868) Embedded server,
 elytron filesystem-realm creation requires reload
In-Reply-To: <JIRA.12670148.1484060965000@Atlassian.JIRA>
References: <JIRA.12670148.1484060965000@Atlassian.JIRA>
	<JIRA.12670148.1484060965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12670148.1484060965000.53030.1487642280885@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-7868:
--------------------------------------

    Assignee: Ken Wills  (was: Brian Stansberry)


> Embedded server, elytron filesystem-realm creation requires reload
> ------------------------------------------------------------------
>
>                 Key: WFLY-7868
>                 URL: https://issues.jboss.org/browse/WFLY-7868
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ken Wills
>
> In embedded server, when elytron filesystem realm is created command response is not marked with {{reload-required}}. However subsequent attempt to use this filesystem realm fails.
> When reload is called between this 2 commands it is OK. 
> When trying on standalone server it is OK.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 21:03:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 21:03: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: <JIRA.12664643.1480543011000@Atlassian.JIRA>
References: <JIRA.12664643.1480543011000@Atlassian.JIRA>
	<JIRA.12664643.1480543011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664643.1480543011000.53039.1487642580155@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366597#comment-13366597 ] 

Brian Stansberry commented on WFCORE-2073:
------------------------------------------

https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-2073

> 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
>
> The ManagedProcess kill() method relies on a scan of running processes that have a command line with -D[<processname>] 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  Mon Feb 20 21:05:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 21:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7709) Native interface got left
 behind standalone-minimalistic.xml config
In-Reply-To: <JIRA.12664527.1480519321000@Atlassian.JIRA>
References: <JIRA.12664527.1480519321000@Atlassian.JIRA>
	<JIRA.12664527.1480519321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664527.1480519321000.53042.1487642700194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-7709:
-----------------------------------
    Summary: Native interface got left behind standalone-minimalistic.xml config  (was: standalone-minimalistic.xml config got left behind)


> Native interface got left behind standalone-minimalistic.xml config
> -------------------------------------------------------------------
>
>                 Key: WFLY-7709
>                 URL: https://issues.jboss.org/browse/WFLY-7709
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.1.0.Final
>            Reporter: Alexey Loubyansky
>            Assignee: Brian Stansberry
>
> Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
> These operations are executed when the minimalistic config is loaded:
> {code}
>   /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
>   /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
>   /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
>   /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
>   /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
>   /socket-binding-group=standard-sockets:add(default-interface="public")
> {code}
> These operations are executed as part of the default core config:
> {code}
>   /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
>   /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
>   /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
>   /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
>   /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 21:31:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 20 Feb 2017 21:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-9) Create initial test suite
In-Reply-To: <JIRA.12676854.1487128784000@Atlassian.JIRA>
References: <JIRA.12676854.1487128784000@Atlassian.JIRA>
	<JIRA.12676854.1487128784000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676854.1487128784000.53047.1487644260284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-9.
----------------------------
    Resolution: Done


> Create initial test suite
> -------------------------
>
>                 Key: AG-9
>                 URL: https://issues.jboss.org/browse/AG-9
>             Project: Agroal
>          Issue Type: Task
>          Components: test
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 21:41:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 21:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2313) The wildfly-config_5_0 xsd
 does not include EAP7.0 and WildFly10.1 in its valid host-release values
In-Reply-To: <JIRA.12677994.1487644849000@Atlassian.JIRA>
References: <JIRA.12677994.1487644849000@Atlassian.JIRA>
	<JIRA.12677994.1487644849627@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677994.1487644849000.53053.1487644860116@Atlassian.JIRA>

Brian Stansberry created WFCORE-2313:
----------------------------------------

             Summary: The wildfly-config_5_0 xsd does not include EAP7.0 and WildFly10.1 in its valid host-release values
                 Key: WFCORE-2313
                 URL: https://issues.jboss.org/browse/WFCORE-2313
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 21:54:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 21:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7709) Native interface got left
 behind in standalone-minimalistic.xml config
In-Reply-To: <JIRA.12664527.1480519321000@Atlassian.JIRA>
References: <JIRA.12664527.1480519321000@Atlassian.JIRA>
	<JIRA.12664527.1480519321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664527.1480519321000.53068.1487645640145@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-7709:
-----------------------------------
    Summary: Native interface got left behind in standalone-minimalistic.xml config  (was: Native interface got left behind standalone-minimalistic.xml config)


> Native interface got left behind in standalone-minimalistic.xml config
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7709
>                 URL: https://issues.jboss.org/browse/WFLY-7709
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.1.0.Final
>            Reporter: Alexey Loubyansky
>            Assignee: Brian Stansberry
>
> Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.
> These operations are executed when the minimalistic config is loaded:
> {code}
>   /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
>   /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
>   /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
>   /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
>   /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
>   /socket-binding-group=standard-sockets:add(default-interface="public")
> {code}
> These operations are executed as part of the default core config:
> {code}
>   /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
>   /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
>   /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
>   /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
>   /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 22:01:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 22:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8170) Native interface got left
 behind in standalone-minimalistic.xml config
In-Reply-To: <JIRA.12677997.1487646004000@Atlassian.JIRA>
References: <JIRA.12677997.1487646004000@Atlassian.JIRA>
	<JIRA.12677997.1487646004466@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677997.1487646004000.53071.1487646060195@Atlassian.JIRA>

Brian Stansberry created WFLY-8170:
--------------------------------------

             Summary: Native interface got left behind in standalone-minimalistic.xml config
                 Key: WFLY-8170
                 URL: https://issues.jboss.org/browse/WFLY-8170
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 10.1.0.Final
            Reporter: Alexey Loubyansky
            Assignee: Brian Stansberry


Analyzing the lists of boot ops from the core and minimalistic configs, I've identified differences in the following operations.

These operations are executed when the minimalistic config is loaded:
{code}
  /core-service=management/security-realm=ManagementRealm:add # map-groups-to-roles is true by default
  /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="9990")
  /socket-binding-group=standard-sockets/socket-binding=management-native:add(interface="management",port="\${jboss.management.native.port:9999}")
  /core-service=management/management-interface=http-interface:add(console-enabled="false",security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http")
  /core-service=management/management-interface=native-interface:add(security-realm="ManagementRealm",socket-binding="management-native") # UNIQUE
  /socket-binding-group=standard-sockets:add(default-interface="public")
{code}
These operations are executed as part of the default core config:
{code}
  /core-service=management/security-realm=ManagementRealm:add(map-groups-to-roles="false")
  /socket-binding-group=standard-sockets/socket-binding=management-http:add(interface="management",port="\${jboss.management.http.port:9990}") # accepts system prop
  /socket-binding-group=standard-sockets/socket-binding=management-https:add(interface="management",port="\${jboss.management.https.port:9993}") # https instead of native
  /core-service=management/management-interface=http-interface:add(security-realm="ManagementRealm",http-upgrade={"enabled" => true},socket-binding="management-http") # console-enabled is true by default
  /socket-binding-group=standard-sockets:add(default-interface="public",port-offset="\${jboss.socket.binding.port-offset:0}") # accepts system prop
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 22:18:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 20 Feb 2017 22:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2314) Incorrectly closed header
 results in not helping IllegalArgumentException with null message
In-Reply-To: <JIRA.12677998.1487647007000@Atlassian.JIRA>
References: <JIRA.12677998.1487647007000@Atlassian.JIRA>
	<JIRA.12677998.1487647007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677998.1487647007000.53120.1487647080240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved JBEAP-8976 to WFCORE-2314:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2314  (was: JBEAP-8976)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: CLI
                       Domain Management
                           (was: CLI)
                           (was: Domain Management)
                           (was: User Experience)
    Affects Version/s:     (was: 7.1.0.DR11)


> Incorrectly closed header results in not helping IllegalArgumentException with null message
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2314
>                 URL: https://issues.jboss.org/browse/WFCORE-2314
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management
>            Reporter: Radim Hatlapatka
>            Assignee: Brian Stansberry
>              Labels: user_experience
>
> Calling {{/core-service=management/security-realm=bbb:add(){allow-resource-service-restart=true)}} (notice incorrectly closed allow-resource-service-restart with ")" instead of "}" results in 
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/security-realm=bbb:add(){allow-resource-service-restart=true)
> {
>     "outcome" => "failed",
>     "failure-description" => "java.lang.IllegalArgumentException:null"
> }
> {noformat}
> with this message in server.log:
> {noformat}
> 14:20:12,440 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 10) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{
>     "address" => [
>         ("core-service" => "management"),
>         ("security-realm" => "bbb")
>     ],
>     "operation" => "add",
>     "operation-headers" => {
>         "allow-resource-service-restart" => "true)",
>         "caller-type" => "user",
>         "access-mechanism" => "NATIVE"
>     }
> }]: java.lang.IllegalArgumentException
> 	at org.jboss.dmr.StringModelValue.asBoolean(StringModelValue.java:157)
> 	at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:346)
> 	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)
> {noformat}
> The IllegalArgumentException should point in the message what argument is incorrect and what is wrong. Printing only null doesn't help much.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 22:23:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 20 Feb 2017 22:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-10) Prepare build infrastructure for
	release
In-Reply-To: <JIRA.12677999.1487647362000@Atlassian.JIRA>
References: <JIRA.12677999.1487647362000@Atlassian.JIRA>
	<JIRA.12677999.1487647362901@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677999.1487647362000.53123.1487647380124@Atlassian.JIRA>

Luis Barreiro created AG-10:
-------------------------------

             Summary: Prepare build infrastructure for release
                 Key: AG-10
                 URL: https://issues.jboss.org/browse/AG-10
             Project: Agroal
          Issue Type: Task
          Components: build
    Affects Versions: 0.0
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro


Configure maven release plugin and make sure artifacts are deployable to JBoss Nexus repo, according to https://developer.jboss.org/docs/DOC-52892



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 22:24:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Mon, 20 Feb 2017 22:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-10) Prepare build infrastructure for
	release
In-Reply-To: <JIRA.12677999.1487647363000@Atlassian.JIRA>
References: <JIRA.12677999.1487647363000@Atlassian.JIRA>
	<JIRA.12677999.1487647363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677999.1487647363000.53126.1487647440147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro updated AG-10:
----------------------------
    Fix Version/s: 0.1


> Prepare build infrastructure for release
> ----------------------------------------
>
>                 Key: AG-10
>                 URL: https://issues.jboss.org/browse/AG-10
>             Project: Agroal
>          Issue Type: Task
>          Components: build
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>
> Configure maven release plugin and make sure artifacts are deployable to JBoss Nexus repo, according to https://developer.jboss.org/docs/DOC-52892



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 23:23:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 23:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8171)
 EJBDefaultSecurityDomainProcessor creates services with a non unique name
In-Reply-To: <JIRA.12678002.1487650947000@Atlassian.JIRA>
References: <JIRA.12678002.1487650947000@Atlassian.JIRA>
	<JIRA.12678002.1487650947000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678002.1487650947000.53132.1487650980451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-8978 to WFLY-8171:
---------------------------------------------

     Project: WildFly  (was: JBoss Enterprise Application Platform)
         Key: WFLY-8171  (was: JBEAP-8978)
    Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)


> EJBDefaultSecurityDomainProcessor creates services with a non unique name
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8171
>                 URL: https://issues.jboss.org/browse/WFLY-8171
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 20 23:24:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 20 Feb 2017 23:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8171)
 EJBDefaultSecurityDomainProcessor creates services with a non unique name
In-Reply-To: <JIRA.12678002.1487650947000@Atlassian.JIRA>
References: <JIRA.12678002.1487650947000@Atlassian.JIRA>
	<JIRA.12678002.1487650947000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678002.1487650947000.53134.1487651040054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8171:
------------------------------------

    Assignee: Stuart Douglas


> EJBDefaultSecurityDomainProcessor creates services with a non unique name
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8171
>                 URL: https://issues.jboss.org/browse/WFLY-8171
>             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  Tue Feb 21 01:28:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Tue, 21 Feb 2017 01:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8172) credential-store and
 authentication-context in Elytron dir-context should be mutually exclusive
In-Reply-To: <JIRA.12678004.1487658466000@Atlassian.JIRA>
References: <JIRA.12678004.1487658466000@Atlassian.JIRA>
	<JIRA.12678004.1487658466412@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678004.1487658466000.53227.1487658481180@Atlassian.JIRA>

Ondrej Lukas created WFLY-8172:
----------------------------------

             Summary: credential-store and authentication-context in Elytron dir-context should be mutually exclusive
                 Key: WFLY-8172
                 URL: https://issues.jboss.org/browse/WFLY-8172
             Project: WildFly
          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 Feb 21 01:54:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 21 Feb 2017 01:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-393) Clone a profile
In-Reply-To: <JIRA.12496563.1373987429000@Atlassian.JIRA>
References: <JIRA.12496563.1373987429000@Atlassian.JIRA>
	<JIRA.12496563.1373987429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496563.1373987429000.53328.1487660040582@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366619#comment-13366619 ] 

RH Bugzilla Integration commented on WFCORE-393:
------------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1125143|https://bugzilla.redhat.com/show_bug.cgi?id=1125143] from ASSIGNED to CLOSED

> Clone a profile
> ---------------
>
>                 Key: WFCORE-393
>                 URL: https://issues.jboss.org/browse/WFCORE-393
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>             Fix For: 2.0.0.Alpha4
>
>
> Add the ability to clone a profile.
> This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly.
> Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 02:47:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 21 Feb 2017 02:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2003) Deliver message batches
In-Reply-To: <JIRA.12599652.1452862428000@Atlassian.JIRA>
References: <JIRA.12599652.1452862428000@Atlassian.JIRA>
	<JIRA.12599652.1452862428000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599652.1452862428000.53490.1487663220149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2003:
---------------------------
    Description: 
Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.

Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once. The default implementation is to pass messages up one-by-one.

This should result in performance increase, as the application can handle multiple messages at once.

  was:
Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.
Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once.
This should result in performance increase, as the application can handle multiple messages at once.



> Deliver message batches
> -----------------------
>
>                 Key: JGRP-2003
>                 URL: https://issues.jboss.org/browse/JGRP-2003
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback.
> Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once. The default implementation is to pass messages up one-by-one.
> This should result in performance increase, as the application can handle multiple messages at once.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 03:48:01 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 21 Feb 2017 03:48:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8173) Make build scripts handle
 default settings.xml correctly
In-Reply-To: <JIRA.12678025.1487666826000@Atlassian.JIRA>
References: <JIRA.12678025.1487666826000@Atlassian.JIRA>
	<JIRA.12678025.1487666826000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678025.1487666826000.53959.1487666881513@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga moved JBEAP-8984 to WFLY-8173:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8173  (was: JBEAP-8984)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Build System
                       Test Suite
                           (was: Build System)
                           (was: Productization)
                           (was: Test Suite)
    Affects Version/s:     (was: 7.1.0.DR12)
      Affects Testing:   (was: Regression)


> Make build scripts handle default settings.xml correctly
> --------------------------------------------------------
>
>                 Key: WFLY-8173
>                 URL: https://issues.jboss.org/browse/WFLY-8173
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System, Test Suite
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>            Priority: Critical
>
> *Wrong behaviour in EAP 7.1.0.DR12*
> * mvnw, build.sh and integration-tests.sh does't use productized settings.xml by default.
> *Desired behaviour*
> * mvnw, build.sh and integration-tests.sh should use productized settings.xml by default.
> *Workaround for build.sh*
> Productized settings.xml needs to be defined manually by "-s" maven property, example:
> ./build.sh clean -Dmaven.repo.local=$NEW_REPO -DallTests -Djboss.test.mixed.domain.dir=$\{HUDSON_STATIC_ENV\}/eap/archives-repository/mixed-domain -s tools/maven/conf/settings.xml
> *Workaround for integration-tests.sh*
> Absolute path needs to be used (see JBEAP-8947), example: "-s /mnt/hudson_workspace/mkopecky/ts/tools/maven/conf/settings.xml"
> *Additional information:*
> * productized settings.xml is added in [this productization commit|http://git.app.eng.bos.redhat.com/git/wildfly/wildfly.git/commit/tools/maven/conf/settings.xml?h=7.1.0.DR12-redhat-fix&id=683ffbac0085d799a1f098337d3a786f9bf1eb7c]
> * "tools/maven/conf/settings.xml" location doesn't make sense, because [download-maven.sh script was removed|https://github.com/jbossas/jboss-eap7/pull/1334/files#diff-d91a6a26c84e56bc56b5270a3549ae7cL1]. But I recommend to keep current location because of backward compatibility



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 04:02:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 21 Feb 2017 04:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8174) broadcast-group capability
 must include the messaging server name
In-Reply-To: <JIRA.12678028.1487667672000@Atlassian.JIRA>
References: <JIRA.12678028.1487667672000@Atlassian.JIRA>
	<JIRA.12678028.1487667672087@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678028.1487667672000.53998.1487667720289@Atlassian.JIRA>

Jeff Mesnil created WFLY-8174:
---------------------------------

             Summary: broadcast-group capability must include the messaging server name
                 Key: WFLY-8174
                 URL: https://issues.jboss.org/browse/WFLY-8174
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


Capabilities registered by the messaging-server's broadcast-group resources are using the pattern:
org.wildfly.messaging.activemq.broadcast-group.channel-factory.<broadcast-group name>

This prevents having 2 broadcast-groups belonging to different ActiveMQ servers using the same name configured in the same profile.

Instead, the ActiveMQ server name should be part of the capability name, e.g.

org.wildfly.messaging.activemq.broadcast-group.channel-factory.<server name>.<broadcast-group name>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 04:28:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 21 Feb 2017 04:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7352) XNIO bridge for Artemis
 doesn't work with newer versions of Netty and Artemis.
In-Reply-To: <JIRA.12655834.1476950731000@Atlassian.JIRA>
References: <JIRA.12655834.1476950731000@Atlassian.JIRA>
	<JIRA.12655834.1476950731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655834.1476950731000.54206.1487669280522@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-7352.
-------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


netty-xnio-transport has been upgrade to 0.1.2.Final and Netty to 4.1.5.Final

> XNIO bridge for Artemis doesn't work with newer versions of Netty and Artemis.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-7352
>                 URL: https://issues.jboss.org/browse/WFLY-7352
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> Test scenario:
> 1. Start server EAP 7.1.0.DR6 (with Artemis 1.4.0) with queue InQueue and OutQueue. Configure non-exclusive divert from InQueue to OutQueue.
> 2. Send large message to InQueue with scheduled delivery 10 seconds
> 3. Start consumer on OutQueue with receive timeout 1000ms and check that NO message was received
> 4. Start consumer on InQueue with receive timeout 1000ms and check that NO message was received
> 5. Start consumer on InQueue with receive timeout 11000ms and check that message is received
> 6. Start consumer on OutQueue with receive timeout 11000ms and check that message is received
> Result:
> Sometimes happens that consumer in step 3. receives a message. By checking trace logs, consumer in step 3. was receiving message 9664ms instead of ~1000ms.
> In attachment is trace log from client and server and test log with client thread dump during ~10s receive.
> Investigation:
> In the moment when client tries to receive a message there is send SessionForceConsumerDelivery packet by client:
> {code}
> 15:07:07,589 Thread-11 INFO  [org.jboss.qa.artemis.test.messages.JmsMessagesTestCase$ReceiveThread:474] Start message comsumption from original queue with receive timeout 1000ms
> 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:386] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000)
> 15:07:07,590 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(1000, false)
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:370] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Returning null
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:392] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}:: receive(1000) -> null, trying again with receive(0)
> 15:07:08,591 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:191] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::receive(0, true)
> 15:07:08,592 Thread-11 TRACE [org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl:301] org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl at 332729ad{consumerContext=ActiveMQConsumerContext{id=0}, queueName=jms.queue.OutQueue}::Forcing delivery
> 15:07:08,593 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:248] Sending packet nonblocking PACKET(SessionForceConsumerDelivery)[type=78, channelID=11, packetObject=SessionForceConsumerDelivery, consumerID=0, sequence=0] on channeID=11
> 15:07:08,604 Thread-11 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl:286] Writing buffer for channelID=11
> {code}
> Response from server comes ~10s later - it's packet SessionReceiveMessage:
> {code}
> 15:07:17,250 Thread-0 (ActiveMQ-client-netty-threads-1138697171) TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl:354] handling packet PACKET(SessionReceiveMessage)[type=75, chan
> nelID=11, packetObject=SessionReceiveMessage, message=ClientMessageImpl[messageID=44, durable=false, address=jms.queue.OutQueue,userID=null,properties=TypedProperties[_hornetq.forced.delivery.seq=0]], consumerID
> =0, deliveryCount=0]
> {code}
> in the mean time client is waiting on - ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:261):
> {noformat}
>  wait(Long.MAX_VALUE);
> {noformat}
> and is waiting for notify. From server log I can see that SessionReceiveMessage was send at:
> {code}
> 15:07:08,621 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Sending packet nonblocking PACKET(SessionReceiveMessage)[type=75, channelID=11, packetObject=SessionReceiveMessage, message=ServerMessage[messageID=44,durable=false,userID=null,priority=0, bodySize=50, timestamp=0,expiration=0, durable=false, address=jms.queue.OutQueue,properties=TypedProperties[_hornetq.forced.delivery.seq=0]]@1525441837, consumerID=0, deliveryCount=0] on channeID=11
> 15:07:08,633 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Writing buffer for channelID=11
> {code}
> but it wasn't flushed and for some reason is actually send ~10s later with the large message:
> {code}
> 15:07:17,236 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Sending pa
> cket nonblocking PACKET(SessionReceiveLargeMessage)[type=76, channelID=11, packetObject=SessionReceiveLargeMessage, consumerID=0, deliveryCount=1, largeMessageSize=409605, message=LargeServerMessage[messageID=40
> ,durable=true,userID=1befe4c2-920f-11e6-9ae8-3ca9f4349bfc,priority=4, timestamp=Fri Oct 14 15:07:07 CEST 2016,expiration=0, durable=true, address=jms.queue.OutQueue,properties=TypedProperties[__AMQ_CID=1bdc35af-
> 920f-11e6-9ae8-3ca9f4349bfc,_AMQ_SCHED_DELIVERY=1476450437224,_AMQ_ORIG_ADDRESS=jms.queue.InQueue,_AMQ_ORIG_MESSAGE_ID=36,counter=0,_AMQ_DUPL_ID=16c2be09-573a-4e02-a369-6a36c2f32fbd,_AMQ_LARGE_SIZE=409605]]@1994
> 218683] on channeID=11
> 15:07:17,246 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 39cb2b3a-1512482465)) Writing bu
> ffer for channelID=11
> 15:07:17,247 TRACE [org.xnio.nio.selector] (default I/O-1) Selected on sun.nio.ch.EPollSelectorImpl at 61ea580a
> 15:07:17,247 TRACE [org.xnio.nio] (default I/O-1) Running task io.netty.channel.AbstractChannelHandlerContext$WriteAndFlushTask at 5c93c5d7
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 05:40:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 05:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-974) Digest uses some properties
 starting com.sun and org.jboss convert to wildfly.
In-Reply-To: <JIRA.12678049.1487673560000@Atlassian.JIRA>
References: <JIRA.12678049.1487673560000@Atlassian.JIRA>
	<JIRA.12678049.1487673560017@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678049.1487673560000.54749.1487673600223@Atlassian.JIRA>

Darran Lofthouse created ELY-974:
------------------------------------

             Summary: Digest uses some properties starting com.sun and org.jboss convert to wildfly.
                 Key: ELY-974
                 URL: https://issues.jboss.org/browse/ELY-974
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: SASL
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta28


Old properties should remain supported but deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 05:59:02 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 21 Feb 2017 05:59:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8175) mvnw wrapper shouldn't
 deppend on .m2/wrapper location
In-Reply-To: <JIRA.12678053.1487674700000@Atlassian.JIRA>
References: <JIRA.12678053.1487674700000@Atlassian.JIRA>
	<JIRA.12678053.1487674700000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678053.1487674700000.54893.1487674742775@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga moved JBEAP-8985 to WFLY-8175:
-------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8175  (was: JBEAP-8985)
             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)


> 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
>
> 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 Feb 21 07:18:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 21 Feb 2017 07:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4
In-Reply-To: <JIRA.12677747.1487591190000@Atlassian.JIRA>
References: <JIRA.12677747.1487591190000@Atlassian.JIRA>
	<JIRA.12677747.1487591190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677747.1487591190000.55637.1487679480603@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13366837#comment-13366837 ] 

Hayk Hovsepyan commented on HAWKULARQE-43:
------------------------------------------

Manual testcase execution is done https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=Hawkular%20Upstream%20-%20EAP6%20Server%20Smoke%20Tests

No regression is found.

> Hawkular Agent for EAP 6.4
> --------------------------
>
>                 Key: HAWKULARQE-43
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-43
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP6%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 07:19:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 21 Feb 2017 07:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-43) Hawkular Agent for EAP 6.4
In-Reply-To: <JIRA.12677747.1487591190000@Atlassian.JIRA>
References: <JIRA.12677747.1487591190000@Atlassian.JIRA>
	<JIRA.12677747.1487591190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677747.1487591190000.55642.1487679540348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan resolved HAWKULARQE-43.
--------------------------------------
    Resolution: Done


Manual smoke test of discovering EAP6 standalone sever is done.
EAP6 domain mode is not supported.

> Hawkular Agent for EAP 6.4
> --------------------------
>
>                 Key: HAWKULARQE-43
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-43
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP6%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 07:52:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 07:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-974) Digest uses property starting
 org.jboss convert to wildfly.
In-Reply-To: <JIRA.12678049.1487673560000@Atlassian.JIRA>
References: <JIRA.12678049.1487673560000@Atlassian.JIRA>
	<JIRA.12678049.1487673560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678049.1487673560000.55908.1487681520685@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-974:
---------------------------------
    Summary: Digest uses property starting org.jboss convert to wildfly.  (was: Digest uses some properties starting com.sun and org.jboss convert to wildfly.)


> Digest uses property starting org.jboss convert to wildfly.
> -----------------------------------------------------------
>
>                 Key: ELY-974
>                 URL: https://issues.jboss.org/browse/ELY-974
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> Old properties should remain supported but deprecated.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 07:59:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 07:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2315) Remoting client from EAP
 7.0.0 can't authenticate against EAP 7.1.0.DR8
In-Reply-To: <JIRA.12678084.1487681900000@Atlassian.JIRA>
References: <JIRA.12678084.1487681900000@Atlassian.JIRA>
	<JIRA.12678084.1487681900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678084.1487681900000.55999.1487681941914@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved JBEAP-8995 to WFCORE-2315:
-------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2315  (was: JBEAP-8995)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Remoting
                       Security
                           (was: EJB)
                           (was: Remoting)
                           (was: Security)
    Affects Version/s: 3.0.0.Beta3
                           (was: 7.1.0.DR8)
      Affects Testing:   (was: Regression)


> Remoting client from EAP 7.0.0 can't authenticate against EAP 7.1.0.DR8
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2315
>                 URL: https://issues.jboss.org/browse/WFCORE-2315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 3.0.0.Beta3
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: authentication, eap71_alpha, regression, remoting, sasl
>
> Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
>    DIGEST-MD5: Server rejected authentication
> {noformat}
> JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms.
> We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 08:00:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 08:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2315) Remoting client from older
 WildFly can't authenticate against latest WildFly Core
In-Reply-To: <JIRA.12678084.1487681900000@Atlassian.JIRA>
References: <JIRA.12678084.1487681900000@Atlassian.JIRA>
	<JIRA.12678084.1487681900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678084.1487681900000.56007.1487682000618@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2315:
-------------------------------------
    Summary: Remoting client from older WildFly can't authenticate against latest WildFly Core  (was: Remoting client from EAP 7.0.0 can't authenticate against EAP 7.1.0.DR8)


> Remoting client from older WildFly can't authenticate against latest WildFly Core
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2315
>                 URL: https://issues.jboss.org/browse/WFCORE-2315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 3.0.0.Beta3
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: authentication, eap71_alpha, regression, remoting, sasl
>
> Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
>    DIGEST-MD5: Server rejected authentication
> {noformat}
> JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms.
> We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 08:00:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 08:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2315) Remoting client from older
 WildFly can't authenticate against latest WildFly Core
In-Reply-To: <JIRA.12678084.1487681900000@Atlassian.JIRA>
References: <JIRA.12678084.1487681900000@Atlassian.JIRA>
	<JIRA.12678084.1487681900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678084.1487681900000.56015.1487682001036@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2315:
-------------------------------------
    Description: 
Using dependencies from older WildFly release, clients are unable to connect to latest WildFly using DIGEST-MD5 mechanism:
{noformat}
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   DIGEST-MD5: Server rejected authentication
{noformat}

JBOSS-LOCAL-USER method works. I'm talking about latest WildFly with legacy security realms.

We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server.

  was:
Using dependencies from EAP 7.0.0, clients are unable to connect to EAP 7.1.0.DR8 using DIGEST-MD5 mechanism:
{noformat}
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   DIGEST-MD5: Server rejected authentication
{noformat}

JBOSS-LOCAL-USER method works. I'm talking about 7.1.0.DR8 with legacy security realms.

We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server.



> Remoting client from older WildFly can't authenticate against latest WildFly Core
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2315
>                 URL: https://issues.jboss.org/browse/WFCORE-2315
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 3.0.0.Beta3
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: authentication, eap71_alpha, regression, remoting, sasl
>
> Using dependencies from older WildFly release, clients are unable to connect to latest WildFly using DIGEST-MD5 mechanism:
> {noformat}
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
>    DIGEST-MD5: Server rejected authentication
> {noformat}
> JBOSS-LOCAL-USER method works. I'm talking about latest WildFly with legacy security realms.
> We are supposed to maintain backward compatibility with older clients but in this case older client won't work against newer server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 08:24:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 21 Feb 2017 08:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8176) CS tool,
 --salt and --iteration parameters unintentionally required
In-Reply-To: <JIRA.12678092.1487683425000@Atlassian.JIRA>
References: <JIRA.12678092.1487683425000@Atlassian.JIRA>
	<JIRA.12678092.1487683425925@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678092.1487683425000.56238.1487683440776@Atlassian.JIRA>

Martin Choma created WFLY-8176:
----------------------------------

             Summary: 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: Darran Lofthouse
            Priority: Blocker


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.<init>(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  Tue Feb 21 08:27:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 21 Feb 2017 08:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.56275.1487683620280@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-972:
---------------------------
    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
* Add user via add-user.sh (as Application User)
* 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 *incorrect* password
* Check that _JBOSS_HOME/standalone/log/audit.log_ is empty
* Open browser in private mode
* Fill username and correct password
* Check that _JBOSS_HOME/standalone/log/audit.log_ has a few inputs


  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
* Add user via add-user.sh (as Application User)
* 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 *incorrect* password
* Check that _JBOSS_HOME/standalone/log/audit.log_ is empty
* Open browser in private mode
* Fill username and correct password
* Check that _JBOSS_HOME/standalone/log/audit.log_ has a few inputs




> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 09:03:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 21 Feb 2017 09:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8177) CS tool,
 2 places to specify credential store location
In-Reply-To: <JIRA.12678108.1487685721000@Atlassian.JIRA>
References: <JIRA.12678108.1487685721000@Atlassian.JIRA>
	<JIRA.12678108.1487685721053@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678108.1487685721000.56474.1487685780290@Atlassian.JIRA>

Martin Choma created WFLY-8177:
----------------------------------

             Summary: CS tool, 2 places to specify credential store location
                 Key: WFLY-8177
                 URL: https://issues.jboss.org/browse/WFLY-8177
             Project: WildFly
          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

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 Feb 21 09:03:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 21 Feb 2017 09:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8177) CS tool,
 2 places to specify credential store location
In-Reply-To: <JIRA.12678108.1487685721000@Atlassian.JIRA>
References: <JIRA.12678108.1487685721000@Atlassian.JIRA>
	<JIRA.12678108.1487685721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678108.1487685721000.56483.1487685780495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8177:
-------------------------------
    Description: 
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.

  was:
Currently there are 2 places, where location can be specified:
- URI parameter
- location parameter

Choose one. In case SPI dictates that, revise SPI.

Setting to high priotity, as possible it is problem of SPI.



> CS tool, 2 places to specify credential store location
> ------------------------------------------------------
>
>                 Key: WFLY-8177
>                 URL: https://issues.jboss.org/browse/WFLY-8177
>             Project: WildFly
>          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 Feb 21 09:22:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 21 Feb 2017 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-959) Coverity static analysis:
 Serializable *Callback classes containes non-serializable fields
In-Reply-To: <JIRA.12672954.1485338215000@Atlassian.JIRA>
References: <JIRA.12672954.1485338215000@Atlassian.JIRA>
	<JIRA.12672954.1485338215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672954.1485338215000.56666.1487686920324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-959:
---------------------------------

    Assignee:     (was: Ilia Vassilev)


> Coverity static analysis: Serializable *Callback classes containes non-serializable fields
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-959
>                 URL: https://issues.jboss.org/browse/ELY-959
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>
> Coverity static analysis found, there is couple of *Callback classes, which  are mark as Serializable, and contains non-serializable fields. 
> * CredentialCallback 
> * CredentialUpdateCallback
> * MechanismInformationCallback
> * SSLCallback
> * SecurityIdentityCallback
> * ServerCredentialCallback
> * TrustedAuthoritiesCallback
> Either mark fields as transient or Serializable.
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8490519&defectInstanceId=2123214&mergedDefectId=1377493



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 09:30:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 21 Feb 2017 09:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-963) Coverity static analysis,
 Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
In-Reply-To: <JIRA.12676552.1487061917000@Atlassian.JIRA>
References: <JIRA.12676552.1487061917000@Atlassian.JIRA>
	<JIRA.12676552.1487061917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676552.1487061917000.56710.1487687400368@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-963:
---------------------------------

    Assignee:     (was: Ilia Vassilev)


> Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
> -----------------------------------------------------------------------------------
>
>                 Key: ELY-963
>                 URL: https://issues.jboss.org/browse/ELY-963
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>
> Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.
> {code:java}
>     private X509Certificate getClientCertificate() throws SaslException {
>         if ((clientCertChain != null) && (clientCertChain.length > 0)) {
>             return clientCertChain[0];
>         } else if (clientCertUrl != null) {
>             try {
>                 return EntityUtil.getCertificateFromUrl(clientCertUrl);
>             } catch (IOException e) {
>                 throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
>             }
>         } else {
>             throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
>         }
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 09:33:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 21 Feb 2017 09:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-962) Coverity: Incorrect definition
 of Serializable classes *PrivateKey (Elytron)
In-Reply-To: <JIRA.12672996.1485350193000@Atlassian.JIRA>
References: <JIRA.12672996.1485350193000@Atlassian.JIRA>
	<JIRA.12672996.1485350193000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672996.1485350193000.56737.1487687580632@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-962:
---------------------------------

    Assignee:     (was: Ilia Vassilev)


> Coverity: Incorrect definition of Serializable classes *PrivateKey (Elytron)
> ----------------------------------------------------------------------------
>
>                 Key: ELY-962
>                 URL: https://issues.jboss.org/browse/ELY-962
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta24
>            Reporter: Martin Choma
>
> There are couple of classes marked as Serializable, but containing non-serializable fields.
> *     RawECPrivateKey
> *     RawDHPrivateKey
> *     RawDSAPrivateKey
> *     RawRSAMultiPrimePrivateCrtKey
> Mark non-serializable fields transient or Serializable
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=8553934&defectInstanceId=2138981&mergedDefectId=1377487



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 09:33:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Tue, 21 Feb 2017 09:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8178) Send module unavailable
 notification when server suspends
In-Reply-To: <JIRA.12678118.1487687571000@Atlassian.JIRA>
References: <JIRA.12678118.1487687571000@Atlassian.JIRA>
	<JIRA.12678118.1487687571902@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678118.1487687571000.56740.1487687580713@Atlassian.JIRA>

Flavia Rainone created WFLY-8178:
------------------------------------

             Summary: 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


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  Tue Feb 21 09:34:00 2017
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 21 Feb 2017 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1170) Build Drools with OpenJDK
 9: switch back to maven-jaxb2-plugin (but it throws ClassNotFoundException:
 com.sun.codemodel.CodeWriter)
In-Reply-To: <JIRA.12618966.1462890333000@Atlassian.JIRA>
References: <JIRA.12618966.1462890333000@Atlassian.JIRA>
	<JIRA.12618966.1462890333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618966.1462890333000.56751.1487687640441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated DROOLS-1170:
-------------------------------------
    Summary: Build Drools with OpenJDK 9: switch back to maven-jaxb2-plugin (but it throws ClassNotFoundException: com.sun.codemodel.CodeWriter)  (was: Build Drools with OpenJDK 9: maven-jaxb2-plugin throws ClassNotFoundException: com.sun.codemodel.CodeWriter)


> Build Drools with OpenJDK 9: switch back to maven-jaxb2-plugin (but it throws ClassNotFoundException: com.sun.codemodel.CodeWriter)
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1170
>                 URL: https://issues.jboss.org/browse/DROOLS-1170
>             Project: Drools
>          Issue Type: Bug
>          Components: build
>            Reporter: Geoffrey De Smet
>            Assignee: Petr ?irok?
>              Labels: java9
>
> See
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-all-build-master-jdk9/
> {code}
> 13:47:25 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc (default) on project drools-pmml: Execution default of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc failed: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 13:47:25 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 13:47:25 	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 13:47:25 	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 13:47:25 	at java.util.concurrent.FutureTask.run(java.base at 9-ea/FutureTask.java:266)
> 13:47:25 	at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 9-ea/Executors.java:514)
> 13:47:25 	at java.util.concurrent.FutureTask.run(java.base at 9-ea/FutureTask.java:266)
> 13:47:25 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158)
> 13:47:25 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632)
> 13:47:25 	at java.lang.Thread.run(java.base at 9-ea/Thread.java:804)
> 13:47:25 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc failed: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:166)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 13:47:25 	... 11 more
> 13:47:25 Caused by: org.apache.maven.plugin.PluginContainerException: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:164)
> 13:47:25 	... 12 more
> 13:47:25 Caused by: java.lang.NoClassDefFoundError: com/sun/codemodel/CodeWriter
> 13:47:25 	at org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo.performExecution(AbstractJavaGeneratorMojo.java:402)
> 13:47:25 	at org.codehaus.mojo.jaxb2.AbstractJaxbMojo.execute(AbstractJaxbMojo.java:257)
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 13:47:25 	... 12 more
> 13:47:25 Caused by: java.lang.ClassNotFoundException: com.sun.codemodel.CodeWriter
> 13:47:25 	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> 13:47:25 	... 15 more
> {code}
> Looks like we need a newer version of the maven-jaxb2-plugin.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 21 09:44:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 21 Feb 2017 09:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8179) The security-vault-askpass
 quickstart is missing mock askpass.sh script
In-Reply-To: <JIRA.12678122.1487688224000@Atlassian.JIRA>
References: <JIRA.12678122.1487688224000@Atlassian.JIRA>
	<JIRA.12678122.1487688224397@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678122.1487688224000.56831.1487688240157@Atlassian.JIRA>

Ivo Studensky created WFLY-8179:
-----------------------------------

             Summary: The security-vault-askpass quickstart is missing mock askpass.sh script
                 Key: WFLY-8179
                 URL: https://issues.jboss.org/browse/WFLY-8179
             Project: WildFly
          Issue Type: Bug
          Components: Quickstarts
    Affects Versions: 10.1.0.Final, 11.0.0.Alpha1
            Reporter: Ivo Studensky
            Assignee: Ivo Studensky


The security-vault-askpass quickstart uses a mock askpass.sh script which seems to be missing in Github repo. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 09:46:00 2017
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 21 Feb 2017 09:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8180) Add core-management extension
 to the feature packs
In-Reply-To: <JIRA.12678119.1487687613000@Atlassian.JIRA>
References: <JIRA.12678119.1487687613000@Atlassian.JIRA>
	<JIRA.12678119.1487687613000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678119.1487687613000.56837.1487688360150@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet moved JBEAP-9002 to WFLY-8180:
------------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8180  (was: JBEAP-9002)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 10.1.0.Final
                           (was: 7.1.0.DR12)


> Add core-management extension to the feature packs
> --------------------------------------------------
>
>                 Key: WFLY-8180
>                 URL: https://issues.jboss.org/browse/WFLY-8180
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 10.1.0.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> The servlet and full distributions don't have the core-management extension defined. Add it to those 2 feature packs.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 10:12:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 21 Feb 2017 10:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8181) broadcast-group capability
 must include the messaging server name
In-Reply-To: <JIRA.12678129.1487689907000@Atlassian.JIRA>
References: <JIRA.12678129.1487689907000@Atlassian.JIRA>
	<JIRA.12678129.1487689907087@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678129.1487689907000.57044.1487689920421@Atlassian.JIRA>

Jeff Mesnil created WFLY-8181:
---------------------------------

             Summary: broadcast-group capability must include the messaging server name
                 Key: WFLY-8181
                 URL: https://issues.jboss.org/browse/WFLY-8181
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


Capabilities registered by the messaging-server's broadcast-group resources are using the pattern:
org.wildfly.messaging.activemq.broadcast-group.channel-factory.<broadcast-group name>

This prevents having 2 broadcast-groups belonging to different ActiveMQ servers using the same name configured in the same profile.

Instead, the ActiveMQ server name should be part of the capability name, e.g.

org.wildfly.messaging.activemq.broadcast-group.channel-factory.<server name>.<broadcast-group name>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 10:39:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 10:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8182) Convert
 *-authentication-factory resources to be child resources of security-domain
In-Reply-To: <JIRA.12678139.1487691522000@Atlassian.JIRA>
References: <JIRA.12678139.1487691522000@Atlassian.JIRA>
	<JIRA.12678139.1487691522817@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678139.1487691522000.57213.1487691540438@Atlassian.JIRA>

Darran Lofthouse created WFLY-8182:
--------------------------------------

             Summary: Convert *-authentication-factory resources to be child resources of security-domain
                 Key: WFLY-8182
                 URL: https://issues.jboss.org/browse/WFLY-8182
             Project: WildFly
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 11.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 Feb 21 11:01:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 11:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-975) Add a
	SecurityDomainAuthenticationClient
In-Reply-To: <JIRA.12678145.1487692825000@Atlassian.JIRA>
References: <JIRA.12678145.1487692825000@Atlassian.JIRA>
	<JIRA.12678145.1487692825107@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678145.1487692825000.57298.1487692860317@Atlassian.JIRA>

Darran Lofthouse created ELY-975:
------------------------------------

             Summary: Add a SecurityDomainAuthenticationClient
                 Key: ELY-975
                 URL: https://issues.jboss.org/browse/ELY-975
             Project: WildFly Elytron
          Issue Type: Feature Request
          Components: API / SPI
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta28


This will be backed by a permission check and obtainable from a SecurityDomain, it will expose methods to enable Evidence verification and authorization to obtain a SecurityIdentity without full access to the ServerAuthenticationContext being required.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 11:04:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 21 Feb 2017 11:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.57338.1487693040763@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367029#comment-13367029 ] 

Jan Kalina commented on ELY-972:
--------------------------------

As the existing audit logging messages are logged under control of ServerAuthenticationContext, I believe we should emit authentication fail messages also here, as part of fail() of approriate States.
Or what is to think here, [~dlofthouse]?

> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 12:12:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 21 Feb 2017 12:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.58207.1487697121173@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367094#comment-13367094 ] 

Jan Kalina commented on ELY-972:
--------------------------------

The only problem is, SecurityAuthenticationFailedEvent accept SecurityIdentity, which is anonymous in captureIdentity - if we want to see who is unsuccessfuly trying to log in, we need to use RealmIdentity - should not it be used in SecurityAuthenticationFailedEvent instead?

> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 12:14:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 12:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.58218.1487697240759@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367095#comment-13367095 ] 

Darran Lofthouse commented on ELY-972:
--------------------------------------

We want to add some new event types to maybe capture the difference between failing the authentication step and the authorization step.

> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 12:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 12:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-975) Add authenticate methods to
	SecurityDomain
In-Reply-To: <JIRA.12678145.1487692825000@Atlassian.JIRA>
References: <JIRA.12678145.1487692825000@Atlassian.JIRA>
	<JIRA.12678145.1487692825000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678145.1487692825000.58220.1487697300474@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-975:
---------------------------------
    Summary: Add authenticate methods to SecurityDomain  (was: Add a SecurityDomainAuthenticationClient)


> Add authenticate methods to SecurityDomain
> ------------------------------------------
>
>                 Key: ELY-975
>                 URL: https://issues.jboss.org/browse/ELY-975
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> This will be backed by a permission check and obtainable from a SecurityDomain, it will expose methods to enable Evidence verification and authorization to obtain a SecurityIdentity without full access to the ServerAuthenticationContext being required.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 12:15:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 12:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-975) Add authenticate methods to
	SecurityDomain
In-Reply-To: <JIRA.12678145.1487692825000@Atlassian.JIRA>
References: <JIRA.12678145.1487692825000@Atlassian.JIRA>
	<JIRA.12678145.1487692825000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678145.1487692825000.58235.1487697300990@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-975:
---------------------------------
    Description: Add authenticate methods to SecurityDomain, this should still have a permission check but is allows code to programatically authenticate without needing access to the ServerAuthenticationContext.  (was: This will be backed by a permission check and obtainable from a SecurityDomain, it will expose methods to enable Evidence verification and authorization to obtain a SecurityIdentity without full access to the ServerAuthenticationContext being required.)


> Add authenticate methods to SecurityDomain
> ------------------------------------------
>
>                 Key: ELY-975
>                 URL: https://issues.jboss.org/browse/ELY-975
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta28
>
>
> Add authenticate methods to SecurityDomain, this should still have a permission check but is allows code to programatically authenticate without needing access to the ServerAuthenticationContext.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 12:42:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Tue, 21 Feb 2017 12:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-38) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12677336.1487269840000@Atlassian.JIRA>
References: <JIRA.12677336.1487269840000@Atlassian.JIRA>
	<JIRA.12677336.1487269840000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677336.1487269840000.58395.1487698920307@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prachi Yadav reassigned HAWKULARQE-38:
--------------------------------------

    Assignee: Prachi Yadav  (was: mfoley user)


> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-38
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-38
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Prachi Yadav
>
> Create manual testcases if not exists.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 13:44:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 21 Feb 2017 13:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7779) ReAuth does not work with
	Elytron
In-Reply-To: <JIRA.12666829.1481322387000@Atlassian.JIRA>
References: <JIRA.12666829.1481322387000@Atlassian.JIRA>
	<JIRA.12666829.1481322387000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666829.1481322387000.58774.1487702640487@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367158#comment-13367158 ] 

Darran Lofthouse commented on WFLY-7779:
----------------------------------------

This is most likely the change you need https://issues.jboss.org/browse/ELY-975 - after obtaining the SecurityDomain a call to authenticate will allow an alternative identity to be obtained after verifying the evidence for that identity.

> ReAuth does not work with Elytron
> ---------------------------------
>
>                 Key: WFLY-7779
>                 URL: https://issues.jboss.org/browse/WFLY-7779
>             Project: WildFly
>          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 Feb 21 14:19:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Tue, 21 Feb 2017 14:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-10) Prepare build infrastructure for
	release
In-Reply-To: <JIRA.12677999.1487647363000@Atlassian.JIRA>
References: <JIRA.12677999.1487647363000@Atlassian.JIRA>
	<JIRA.12677999.1487647363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677999.1487647363000.58933.1487704740226@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-10.
-----------------------------
    Resolution: Done


> Prepare build infrastructure for release
> ----------------------------------------
>
>                 Key: AG-10
>                 URL: https://issues.jboss.org/browse/AG-10
>             Project: Agroal
>          Issue Type: Task
>          Components: build
>    Affects Versions: 0.0
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.1
>
>
> Configure maven release plugin and make sure artifacts are deployable to JBoss Nexus repo, according to https://developer.jboss.org/docs/DOC-52892



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 16:26:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 21 Feb 2017 16:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8183) Anonymous Elytron SASL
 authentication fails for JMS
In-Reply-To: <JIRA.12678207.1487712320000@Atlassian.JIRA>
References: <JIRA.12678207.1487712320000@Atlassian.JIRA>
	<JIRA.12678207.1487712320093@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678207.1487712320000.59279.1487712360791@Atlassian.JIRA>

Josef Cacek created WFLY-8183:
---------------------------------

             Summary: Anonymous Elytron SASL authentication fails for JMS
                 Key: WFLY-8183
                 URL: https://issues.jboss.org/browse/WFLY-8183
             Project: WildFly
          Issue Type: Bug
          Components: JMS, Security
            Reporter: Josef Cacek
            Assignee: Jeff Mesnil
            Priority: Blocker


Anonymous JMS client access is not possible with Elytron.

When the ANONYMOUS SASL mechanism is configured, then creating A-MQ session fails with:

{code}
22:06:26,119 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: java.lang.IllegalArgumentException: Parameter 'guess' may not be null
	at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70)
	at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48)
	at org.wildfly.security.evidence.PasswordGuessEvidence.<init>(PasswordGuessEvidence.java:40)
	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:87)
	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:627)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
	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)
{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 18:42:02 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 21 Feb 2017 18:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8184) Singleton deployment not
 stopped on the previous singleton provider after new provider is elected
In-Reply-To: <JIRA.12678214.1487720474000@Atlassian.JIRA>
References: <JIRA.12678214.1487720474000@Atlassian.JIRA>
	<JIRA.12678214.1487720474000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678214.1487720474000.59539.1487720522405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-9010 to WFLY-8184:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8184  (was: JBEAP-9010)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                           (was: Clustering)
    Affects Version/s:     (was: 7.1.0.DR8)
                           (was: 7.1.0.DR9)
                           (was: 7.1.0.DR10)
                           (was: 7.1.0.DR11)
      Affects Testing:   (was: Regression)


> Singleton deployment not stopped on the previous singleton provider after new provider is elected
> -------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8184
>                 URL: https://issues.jboss.org/browse/WFLY-8184
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>
> Scenario: failover clustering test with singleton deployment.
> {code:xml|title=Singleton subsystem configuration}
> <subsystem xmlns="urn:jboss:domain:singleton:1.0">
>   <singleton-policies default="default">
>     <singleton-policy name="default" cache-container="server">
>       <random-election-policy/>
>     </singleton-policy>
>   </singleton-policies>
> </subsystem>
> {code}
> Nodes startup order: node1, node2, node3, node4.
> During node1 startup, this server is elected as the singleton provider and deploys singleton deployment. During other servers startup, some other node (usually node2) is elected as the singleton provider and deploys singleton deployment. However, node1 has the singleton deployment still deployed, so there are *2 nodes* effectively providing a singleton deployment.
> Deployment used: [clusterbench-ee7-singleton-jbossall.ear|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-clusterbench-singleton/1/artifact/clusterbench-ee7-singleton-jbossall.ear|http://example.com]
> Standard clusterbench application with modified jboss-all.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss xmlns="urn:jboss:1.0">
>     <singleton-deployment xmlns="urn:jboss:singleton-deployment:1.0"/>
> </jboss>
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failover-singleton-deployment-jvmkill-random-election-policy/7/console-perf18/



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 21 22:12:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 21 Feb 2017 22:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.59636.1487733120091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367238#comment-13367238 ] 

Edson Tirelli commented on DROOLS-1432:
---------------------------------------

Made more progress, but unfortunately not done yet:

https://github.com/droolsjbpm/kie-dmn/pull/35/files



> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 02:03:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
In-Reply-To: <JIRA.12678226.1487746937000@Atlassian.JIRA>
References: <JIRA.12678226.1487746937000@Atlassian.JIRA>
	<JIRA.12678226.1487746937860@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746937000.59771.1487746980450@Atlassian.JIRA>

Martin Choma created WFLY-8185:
----------------------------------

             Summary: Introduce credential-store.sh
                 Key: WFLY-8185
                 URL: https://issues.jboss.org/browse/WFLY-8185
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Currently there is just delivered wildfly-elytron-tool.jar in ${EAP_HOME}/bin folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line ;)
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 02:03:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
In-Reply-To: <JIRA.12678226.1487746938000@Atlassian.JIRA>
References: <JIRA.12678226.1487746938000@Atlassian.JIRA>
	<JIRA.12678226.1487746938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746938000.59780.1487746980727@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8185:
-------------------------------
    Description: 
Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 


  was:
Currently there is just delivered wildfly-elytron-tool.jar in ${EAP_HOME}/bin folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
- It saves space on command line ;)
- It is analogous to vault.sh - so obvious when looking for credential store tool
- With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
- Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 




> Introduce credential-store.sh
> -----------------------------
>
>                 Key: WFLY-8185
>                 URL: https://issues.jboss.org/browse/WFLY-8185
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              Labels: credential-store
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 02:04:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8185) Introduce credential-store.sh
In-Reply-To: <JIRA.12678226.1487746938000@Atlassian.JIRA>
References: <JIRA.12678226.1487746938000@Atlassian.JIRA>
	<JIRA.12678226.1487746938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746938000.59793.1487747040642@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8185:
-------------------------------
    Labels: credential-store user_experience  (was: credential-store)


> Introduce credential-store.sh
> -----------------------------
>
>                 Key: WFLY-8185
>                 URL: https://issues.jboss.org/browse/WFLY-8185
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              Labels: credential-store, user_experience
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 02:47:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool,
 can't list --help without NPE occurence
In-Reply-To: <JIRA.12678231.1487749599000@Atlassian.JIRA>
References: <JIRA.12678231.1487749599000@Atlassian.JIRA>
	<JIRA.12678231.1487749599579@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678231.1487749599000.60026.1487749620705@Atlassian.JIRA>

Martin Choma created WFLY-8186:
----------------------------------

             Summary: 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


{code}
java -jar wildfly-elytron-tool.jar credential-store -h 
{code}

or because of JBEAP-8996

{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 <sub-command>
       <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
       <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
       <arg>]

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.<init>(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 Feb 22 02:48:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool,
 can't list --help without NPE occurence
In-Reply-To: <JIRA.12678231.1487749600000@Atlassian.JIRA>
References: <JIRA.12678231.1487749600000@Atlassian.JIRA>
	<JIRA.12678231.1487749600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678231.1487749600000.60051.1487749680978@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8186:
-------------------------------
    Description: 
{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 <sub-command>
       <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
       <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
       <arg>]

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.<init>(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}


  was:
{code}
java -jar wildfly-elytron-tool.jar credential-store -h 
{code}

or because of JBEAP-8996

{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 <sub-command>
       <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
       <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
       <arg>]

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.<init>(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}




> 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
>
> {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 <sub-command>
>        <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
>        <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
>        <arg>]
> 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.<init>(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 Feb 22 02:49:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 02:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8186) CS tool,
 can't list --help without NPE occurence
In-Reply-To: <JIRA.12678231.1487749600000@Atlassian.JIRA>
References: <JIRA.12678231.1487749600000@Atlassian.JIRA>
	<JIRA.12678231.1487749600000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678231.1487749600000.60071.1487749740647@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8186:
-------------------------------
    Labels: credential-store  (was: )


> 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 <sub-command>
>        <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
>        <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
>        <arg>]
> 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.<init>(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 Feb 22 03:00:02 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 03:00:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8187) CS tool,
 omitting required param leads to NPE
In-Reply-To: <JIRA.12678233.1487750374000@Atlassian.JIRA>
References: <JIRA.12678233.1487750374000@Atlassian.JIRA>
	<JIRA.12678233.1487750374816@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678233.1487750374000.60173.1487750402101@Atlassian.JIRA>

Martin Choma created WFLY-8187:
----------------------------------

             Summary: CS tool, omitting required param leads to NPE
                 Key: WFLY-8187
                 URL: https://issues.jboss.org/browse/WFLY-8187
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


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.<init>(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  Wed Feb 22 03:13:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 03:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8188) CS tool,
 add prompt when --password is missing
In-Reply-To: <JIRA.12678236.1487751155000@Atlassian.JIRA>
References: <JIRA.12678236.1487751155000@Atlassian.JIRA>
	<JIRA.12678236.1487751155549@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678236.1487751155000.60227.1487751180455@Atlassian.JIRA>

Martin Choma created WFLY-8188:
----------------------------------

             Summary: CS tool, add prompt when --password is missing
                 Key: WFLY-8188
                 URL: https://issues.jboss.org/browse/WFLY-8188
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


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  Wed Feb 22 03:21:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 03:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8189) CS tool,
 add prompt when --secret is missing
In-Reply-To: <JIRA.12678239.1487751651000@Atlassian.JIRA>
References: <JIRA.12678239.1487751651000@Atlassian.JIRA>
	<JIRA.12678239.1487751651740@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678239.1487751651000.60283.1487751661453@Atlassian.JIRA>

Martin Choma created WFLY-8189:
----------------------------------

             Summary: CS tool, add prompt when --secret is missing
                 Key: WFLY-8189
                 URL: https://issues.jboss.org/browse/WFLY-8189
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


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  Wed Feb 22 03:41:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 22 Feb 2017 03:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-976) Elytron Audit Logging's event
 timestamp lacks information about seconds
In-Reply-To: <JIRA.12678242.1487752844000@Atlassian.JIRA>
References: <JIRA.12678242.1487752844000@Atlassian.JIRA>
	<JIRA.12678242.1487752844587@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678242.1487752844000.60475.1487752861090@Atlassian.JIRA>

Jan Tymel created ELY-976:
-----------------------------

             Summary: Elytron Audit Logging's event timestamp lacks information about seconds
                 Key: ELY-976
                 URL: https://issues.jboss.org/browse/ELY-976
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Jan Tymel
            Assignee: Darran Lofthouse
            Priority: Blocker


The format of Elytron Audit Logging's event timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users.
Furthermore the format of timestamp is inconsistent with the one used in Management Audit Logging:


_Elytron Audit Logging:_
{code}
2/22/17 9:08 AM
{code}
_Management Audit Logging:_
{code}
2017-02-22 09:08:00
{code}

Suggestions for improvement:
Use the same format of timestamp in Elytron Audit Logging as is already used in Management Audit Logging.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 03:41:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 22 Feb 2017 03:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-976) Elytron Audit Logging's event
 timestamp lacks information about seconds
In-Reply-To: <JIRA.12678242.1487752845000@Atlassian.JIRA>
References: <JIRA.12678242.1487752845000@Atlassian.JIRA>
	<JIRA.12678242.1487752845000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678242.1487752845000.60479.1487752861168@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reassigned ELY-976:
-----------------------------

    Assignee:     (was: Darran Lofthouse)


> Elytron Audit Logging's event timestamp lacks information about seconds
> -----------------------------------------------------------------------
>
>                 Key: ELY-976
>                 URL: https://issues.jboss.org/browse/ELY-976
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> The format of Elytron Audit Logging's event timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users.
> Furthermore the format of timestamp is inconsistent with the one used in Management Audit Logging:
> _Elytron Audit Logging:_
> {code}
> 2/22/17 9:08 AM
> {code}
> _Management Audit Logging:_
> {code}
> 2017-02-22 09:08:00
> {code}
> Suggestions for improvement:
> Use the same format of timestamp in Elytron Audit Logging as is already used in Management Audit Logging.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 03:42:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 22 Feb 2017 03:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-976) Elytron Audit Logging's event
 timestamp lacks information about seconds
In-Reply-To: <JIRA.12678242.1487752845000@Atlassian.JIRA>
References: <JIRA.12678242.1487752845000@Atlassian.JIRA>
	<JIRA.12678242.1487752845000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678242.1487752845000.60483.1487752920269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated ELY-976:
--------------------------
    Attachment: standalone.xml


> Elytron Audit Logging's event timestamp lacks information about seconds
> -----------------------------------------------------------------------
>
>                 Key: ELY-976
>                 URL: https://issues.jboss.org/browse/ELY-976
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Priority: Blocker
>         Attachments: deployment.war, standalone.xml
>
>
> The format of Elytron Audit Logging's event timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users.
> Furthermore the format of timestamp is inconsistent with the one used in Management Audit Logging:
> _Elytron Audit Logging:_
> {code}
> 2/22/17 9:08 AM
> {code}
> _Management Audit Logging:_
> {code}
> 2017-02-22 09:08:00
> {code}
> Suggestions for improvement:
> Use the same format of timestamp in Elytron Audit Logging as is already used in Management Audit Logging.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 03:42:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 22 Feb 2017 03:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-976) Elytron Audit Logging's event
 timestamp lacks information about seconds
In-Reply-To: <JIRA.12678242.1487752845000@Atlassian.JIRA>
References: <JIRA.12678242.1487752845000@Atlassian.JIRA>
	<JIRA.12678242.1487752845000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678242.1487752845000.60485.1487752920347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated ELY-976:
--------------------------
    Attachment: deployment.war


> Elytron Audit Logging's event timestamp lacks information about seconds
> -----------------------------------------------------------------------
>
>                 Key: ELY-976
>                 URL: https://issues.jboss.org/browse/ELY-976
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Priority: Blocker
>         Attachments: deployment.war, standalone.xml
>
>
> The format of Elytron Audit Logging's event timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users.
> Furthermore the format of timestamp is inconsistent with the one used in Management Audit Logging:
> _Elytron Audit Logging:_
> {code}
> 2/22/17 9:08 AM
> {code}
> _Management Audit Logging:_
> {code}
> 2017-02-22 09:08:00
> {code}
> Suggestions for improvement:
> Use the same format of timestamp in Elytron Audit Logging as is already used in Management Audit Logging.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 03:43:00 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Wed, 22 Feb 2017 03:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-972) Elytron Audit Logging does not
 log failed authentication
In-Reply-To: <JIRA.12677931.1487604496000@Atlassian.JIRA>
References: <JIRA.12677931.1487604496000@Atlassian.JIRA>
	<JIRA.12677931.1487604496000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677931.1487604496000.60489.1487752980332@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated ELY-972:
--------------------------
    Attachment: deployment.war


> Elytron Audit Logging does not log failed authentication
> --------------------------------------------------------
>
>                 Key: ELY-972
>                 URL: https://issues.jboss.org/browse/ELY-972
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Tymel
>            Assignee: Jan Kalina
>            Priority: Blocker
>         Attachments: deployment.war
>
>
> Successful authentication is correctly handled by Elytron Audit Logging. However, if user provides incorrect password (~ authentication fails) there is no such record in audit log file.
> Logging of failed authentication is one of the requirements for this Elytron Audit Logging feature. Therefore setting blocker priority.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 04:04:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 22 Feb 2017 04:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8190) Make OpenSAML private
In-Reply-To: <JIRA.12678246.1487754161000@Atlassian.JIRA>
References: <JIRA.12678246.1487754161000@Atlassian.JIRA>
	<JIRA.12678246.1487754161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678246.1487754161000.60600.1487754240181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved JBEAP-9021 to WFLY-8190:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8190  (was: JBEAP-9021)
           Issue Type: Task  (was: Bug)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Build System
                           (was: Build System)
    Affects Version/s:     (was: 7.0.0.GA)


> Make OpenSAML private
> ---------------------
>
>                 Key: WFLY-8190
>                 URL: https://issues.jboss.org/browse/WFLY-8190
>             Project: WildFly
>          Issue Type: Task
>          Components: Build System
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> See if it can be private. We are not providing OpenSAML, we are providing SAML capability via our JEE Webservices, so storage & messaging jars must not be required to provide our JAXWS capabilities, thus we do not ship them. Right now is public so users would expect to have the storage & messaging at least in the BOM files.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 04:22:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Wed, 22 Feb 2017 04:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.60721.1487755320530@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367315#comment-13367315 ] 

Martin Simka commented on WFLY-8141:
------------------------------------

[~brian.stansberry] I'm missing {{:add(install="true")}} in requirements above. Shouldn't it be there? Removing it was incompatible change as this jira shows. 

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 04:29:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 04:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8191) CS tool,
	review usage documentation
In-Reply-To: <JIRA.12678258.1487755697000@Atlassian.JIRA>
References: <JIRA.12678258.1487755697000@Atlassian.JIRA>
	<JIRA.12678258.1487755697012@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678258.1487755697000.60859.1487755740503@Atlassian.JIRA>

Martin Choma created WFLY-8191:
----------------------------------

             Summary: CS tool, review usage documentation
                 Key: WFLY-8191
                 URL: https://issues.jboss.org/browse/WFLY-8191
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


Current usage output
{code}
usage: java -jar wildfly-elytron-tool.jar credential-store <sub-command>
       <options> -a <arg> | -e <arg> | -h | -r <arg> | -v [-c]  [-f]  [-i
       <arg>] [-l <arg>] [-p <arg>]  [-s <arg>] [-t <arg>] [-u <arg>]  [-x
       <arg>]
 -a,--add <arg>         Add new alias to the credential store
 -c,--create            Create credential store [true/false]
 -e,--exists <arg>      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 <arg>   Iteration count for for final masked password of
                        the credential store
 -l,--location <arg>    Location of credential store storage file
 -p,--password <arg>    Password for credential store
 -r,--remove <arg>      Remove alias from the 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
 -v,--aliases           Display all aliases
 -x,--secret <arg>      Password credential value
{code}

IMO suffers with these issues:
- it introduce misleading <sub-command> 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 <arg> 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  Wed Feb 22 04:51:01 2017
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 22 Feb 2017 04:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2216) CLI fails to reload when
 connection upgrades from http to https
In-Reply-To: <JIRA.12672103.1484843632000@Atlassian.JIRA>
References: <JIRA.12672103.1484843632000@Atlassian.JIRA>
	<JIRA.12672103.1484843632000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672103.1484843632000.61130.1487757061272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky updated WFCORE-2216:
-----------------------------------
    Attachment: test_log
                thread_dump


> CLI fails to reload when connection upgrades from http to https
> ---------------------------------------------------------------
>
>                 Key: WFCORE-2216
>                 URL: https://issues.jboss.org/browse/WFCORE-2216
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>         Attachments: test_log, thread_dump
>
>
> reload command should manage to reconnect to a server reconfigured with https management interface.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 04:54:00 2017
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Wed, 22 Feb 2017 04:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2216) CLI fails to reload when
 connection upgrades from http to https
In-Reply-To: <JIRA.12672103.1484843632000@Atlassian.JIRA>
References: <JIRA.12672103.1484843632000@Atlassian.JIRA>
	<JIRA.12672103.1484843632000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672103.1484843632000.61177.1487757240724@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367348#comment-13367348 ] 

Petr Kremensky commented on WFCORE-2216:
----------------------------------------

Hi guys,
ReloadRedirectTestCase stuck on our HP-UX builds (3.0.0.Beta2).

I'll try to look more into this later this week and create a new Jira eventually ( [^test_log]  [^thread_dump] )

cc [~mkopecky]


> CLI fails to reload when connection upgrades from http to https
> ---------------------------------------------------------------
>
>                 Key: WFCORE-2216
>                 URL: https://issues.jboss.org/browse/WFCORE-2216
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Alpha23
>
>         Attachments: test_log, thread_dump
>
>
> reload command should manage to reconnect to a server reconfigured with https management interface.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 04:57:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 04:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8192) CS tool,
 Add possibility to produce masked password
In-Reply-To: <JIRA.12678265.1487757367000@Atlassian.JIRA>
References: <JIRA.12678265.1487757367000@Atlassian.JIRA>
	<JIRA.12678265.1487757367147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678265.1487757367000.61210.1487757420341@Atlassian.JIRA>

Martin Choma created WFLY-8192:
----------------------------------

             Summary: CS tool, Add possibility to produce masked password
                 Key: WFLY-8192
                 URL: https://issues.jboss.org/browse/WFLY-8192
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


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  Wed Feb 22 04:57:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 04:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8192) CS tool,
 Add possibility to produce masked password
In-Reply-To: <JIRA.12678265.1487757367000@Atlassian.JIRA>
References: <JIRA.12678265.1487757367000@Atlassian.JIRA>
	<JIRA.12678265.1487757367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678265.1487757367000.61221.1487757420784@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8192:
-------------------------------
    Labels: credential-store user_experience  (was: credential-store)


> CS tool, Add possibility to produce masked password
> ---------------------------------------------------
>
>                 Key: WFLY-8192
>                 URL: https://issues.jboss.org/browse/WFLY-8192
>             Project: WildFly
>          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  Wed Feb 22 05:36:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Feb 2017 05:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2316) Introduce
	credential-store.sh
In-Reply-To: <JIRA.12678226.1487746938000@Atlassian.JIRA>
References: <JIRA.12678226.1487746938000@Atlassian.JIRA>
	<JIRA.12678226.1487746938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746938000.61595.1487759761308@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-8185 to WFCORE-2316:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2316  (was: WFLY-8185)
    Component/s: Security
                     (was: Security)


> Introduce credential-store.sh
> -----------------------------
>
>                 Key: WFCORE-2316
>                 URL: https://issues.jboss.org/browse/WFCORE-2316
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              Labels: credential-store, user_experience
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 05:36:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Feb 2017 05:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2316) Introduce
	credential-store.sh
In-Reply-To: <JIRA.12678226.1487746938000@Atlassian.JIRA>
References: <JIRA.12678226.1487746938000@Atlassian.JIRA>
	<JIRA.12678226.1487746938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746938000.61602.1487759761720@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-2316:
-------------------------------------
    Issue Type: Feature Request  (was: Bug)


> Introduce credential-store.sh
> -----------------------------
>
>                 Key: WFCORE-2316
>                 URL: https://issues.jboss.org/browse/WFCORE-2316
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              Labels: credential-store, user_experience
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 05:37:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Feb 2017 05:37:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2316) Introduce
	credential-store.sh
In-Reply-To: <JIRA.12678226.1487746938000@Atlassian.JIRA>
References: <JIRA.12678226.1487746938000@Atlassian.JIRA>
	<JIRA.12678226.1487746938000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678226.1487746938000.61642.1487759823038@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367380#comment-13367380 ] 

Darran Lofthouse commented on WFCORE-2316:
------------------------------------------

Not convinced we need one but if a script was added it would need to be wildfly-elytron-tool.sh and not specific to the credential store.

> Introduce credential-store.sh
> -----------------------------
>
>                 Key: WFCORE-2316
>                 URL: https://issues.jboss.org/browse/WFCORE-2316
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>              Labels: credential-store, user_experience
>
> Currently there is just delivered wildfly-elytron-tool.jar in {{$EAP_HOME/bin}} folder. I think for convenience it would be better if it will contain also  credential-store.sh script, although now it will be just java -jar wildfly-elytron-tool.jar credential-store
> - It saves space on command line
> - It is analogous to vault.sh - so obvious when looking for credential store tool
> - With such script we gain customization point for credential store. As wildfly-elytron-tool.jar will expand, it is possible some credential-store customization for starting tool will be necessary
> - Once wildlfy elytron tool will be exposed with modules, script can be updated to start with modules with no change for user 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 06:49:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 22 Feb 2017 06:49:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8193) Incorrect realm for
 DIGEST-MD5 when Elytron SASL global factory is directly used
In-Reply-To: <JIRA.12678279.1487764120000@Atlassian.JIRA>
References: <JIRA.12678279.1487764120000@Atlassian.JIRA>
	<JIRA.12678279.1487764120270@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678279.1487764120000.62372.1487764141941@Atlassian.JIRA>

Ondrej Lukas created WFLY-8193:
----------------------------------

             Summary: Incorrect realm for DIGEST-MD5 when Elytron SASL global factory is directly used
                 Key: WFLY-8193
                 URL: https://issues.jboss.org/browse/WFLY-8193
             Project: WildFly
          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  Wed Feb 22 06:52:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 22 Feb 2017 06:52:01 -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: <JIRA.12678282.1487764311000@Atlassian.JIRA>
References: <JIRA.12678282.1487764311000@Atlassian.JIRA>
	<JIRA.12678282.1487764311752@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678282.1487764311000.62408.1487764321551@Atlassian.JIRA>

Ondrej Lukas created WFLY-8194:
----------------------------------

             Summary: 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: Darran Lofthouse
            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 feature works correctly in EAP 7.1.0.DR11.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 06:52:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 22 Feb 2017 06:52:01 -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: <JIRA.12678282.1487764312000@Atlassian.JIRA>
References: <JIRA.12678282.1487764312000@Atlassian.JIRA>
	<JIRA.12678282.1487764312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678282.1487764312000.62417.1487764321970@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8194:
-------------------------------
    Description: 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.  (was: 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 feature works correctly in EAP 7.1.0.DR11.)


> 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: Darran Lofthouse
>            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 Feb 22 06:53:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 22 Feb 2017 06:53: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: <JIRA.12678282.1487764312000@Atlassian.JIRA>
References: <JIRA.12678282.1487764312000@Atlassian.JIRA>
	<JIRA.12678282.1487764312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678282.1487764312000.62423.1487764380546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8194:
-------------------------------
    Steps to Reproduce: 
1) Add user - add following line to {{standalone/configuration/mgmt-users.properties}}
{code}
user1=pass at 123
{code}

2) Configure application server:
{code}
/subsystem=elytron/sasl-authentication-factory=elytronSaslAuthnFactory:add(security-domain=ManagementDomain,sasl-server-factory=global,mechanism-configurations=[{mechanism-name=PLAIN}])
/subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true)
{code}

3) Change http-interface to following:
{code}
<http-interface http-authentication-factory="management-http-authentication">
    <http-upgrade enabled="true" sasl-authentication-factory="elytronSaslAuthnFactory"/>
    <socket-binding http="management-http"/>
</http-interface>
{code}

4) try to authenticate to jboss CLI:
{code}
./jboss-cli.sh -c -u=user1 -p=pass at 123 --no-local-auth
Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: JBREM000202: Abrupt close on Remoting connection 25b770fb to localhost/127.0.0.1:9990 of endpoint "cli-client" <5a992706>
{code}

  was:
These steps work correctly with EAP 7.1.0.DR11, but fail with EAP 7.1.0.DR12:
1) Add user - add following line to {{standalone/configuration/mgmt-users.properties}}
{code}
user1=pass at 123
{code}

2) Configure application server:
{code}
/subsystem=elytron/sasl-authentication-factory=elytronSaslAuthnFactory:add(security-domain=ManagementDomain,sasl-server-factory=global,mechanism-configurations=[{mechanism-name=PLAIN}])
/subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true)
{code}

3) Change http-interface to following:
{code}
<http-interface http-authentication-factory="management-http-authentication">
    <http-upgrade enabled="true" sasl-authentication-factory="elytronSaslAuthnFactory"/>
    <socket-binding http="management-http"/>
</http-interface>
{code}

4) try to authenticate to jboss CLI:
{code}
./jboss-cli.sh -c -u=user1 -p=pass at 123 --no-local-auth
Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: JBREM000202: Abrupt close on Remoting connection 25b770fb to localhost/127.0.0.1:9990 of endpoint "cli-client" <5a992706>
{code}



> 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: Darran Lofthouse
>            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 Feb 22 07:13:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 07:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8195) CS tool,
 provide way to create empty credential store
In-Reply-To: <JIRA.12678287.1487765529000@Atlassian.JIRA>
References: <JIRA.12678287.1487765529000@Atlassian.JIRA>
	<JIRA.12678287.1487765529557@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678287.1487765529000.62589.1487765580600@Atlassian.JIRA>

Martin Choma created WFLY-8195:
----------------------------------

             Summary: CS tool, provide way to create empty credential store
                 Key: WFLY-8195
                 URL: https://issues.jboss.org/browse/WFLY-8195
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


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  Wed Feb 22 07:38:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 07:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8196) CS tool,
	invalid options are accepted
In-Reply-To: <JIRA.12678293.1487767044000@Atlassian.JIRA>
References: <JIRA.12678293.1487767044000@Atlassian.JIRA>
	<JIRA.12678293.1487767044553@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678293.1487767044000.62784.1487767080703@Atlassian.JIRA>

Martin Choma created WFLY-8196:
----------------------------------

             Summary: CS tool, invalid options are accepted
                 Key: WFLY-8196
                 URL: https://issues.jboss.org/browse/WFLY-8196
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


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  Wed Feb 22 07:57:00 2017
From: issues at jboss.org (Jan Pazdziora (JIRA))
Date: Wed, 22 Feb 2017 07:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8197) Following
 https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with
 wildfly-10.1.0-7.fc25.noarch fails
In-Reply-To: <JIRA.12678302.1487768181000@Atlassian.JIRA>
References: <JIRA.12678302.1487768181000@Atlassian.JIRA>
	<JIRA.12678302.1487768181300@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678302.1487768181000.63003.1487768220513@Atlassian.JIRA>

Jan Pazdziora created WFLY-8197:
-----------------------------------

             Summary: Following https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with wildfly-10.1.0-7.fc25.noarch fails
                 Key: WFLY-8197
                 URL: https://issues.jboss.org/browse/WFLY-8197
             Project: WildFly
          Issue Type: Bug
         Environment: wildfly-10.1.0-7.fc25.noarch
            Reporter: Jan Pazdziora
            Assignee: Jason Greene
            Priority: Trivial


I try to follow the README in this quickstart but the parameters to the keytool command seem to create keystore which vault.sh does not like, resulting in


{noformat}
Problem occurred:
java.lang.Exception: WFLYSEC0045: Exception encountered:
	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:194)
	at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:212)
	at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
	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:330)
	at org.jboss.modules.Main.main(Main.java:505)
Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:487)
	at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:214)
	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:191)
	... 9 more
Caused by: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVersionedVaultContent(PicketBoxSecurityVault.java:609)
	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:480)
	... 11 more
{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 07:59:03 2017
From: issues at jboss.org (Jan Pazdziora (JIRA))
Date: Wed, 22 Feb 2017 07:59:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8197) Following
 https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with
 wildfly-10.1.0-7.fc25.noarch fails
In-Reply-To: <JIRA.12678302.1487768181000@Atlassian.JIRA>
References: <JIRA.12678302.1487768181000@Atlassian.JIRA>
	<JIRA.12678302.1487768181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678302.1487768181000.63092.1487768343493@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367488#comment-13367488 ] 

Jan Pazdziora commented on WFLY-8197:
-------------------------------------

Using JCEKS, AES, and 256, for example with

{noformat}
keytool -storetype jceks -genseckey -alias vault -keystore vault.keystore -keyalg AES -keysize 256 -storepass vault22 -keypass vault22 -dname "CN=Picketbox vault,OU=picketbox,O=JBoss,L=chicago,ST=il,C=us"
{noformat}

Makes both commands pass.

But I have no idea if that's what is intended here.

> Following https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with wildfly-10.1.0-7.fc25.noarch fails
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8197
>                 URL: https://issues.jboss.org/browse/WFLY-8197
>             Project: WildFly
>          Issue Type: Bug
>         Environment: wildfly-10.1.0-7.fc25.noarch
>            Reporter: Jan Pazdziora
>            Assignee: Jason Greene
>            Priority: Trivial
>
> I try to follow the README in this quickstart but the parameters to the keytool command seem to create keystore which vault.sh does not like, resulting in
> {noformat}
> Problem occurred:
> java.lang.Exception: WFLYSEC0045: Exception encountered:
> 	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:194)
> 	at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:212)
> 	at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
> 	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
> 	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:330)
> 	at org.jboss.modules.Main.main(Main.java:505)
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:487)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:214)
> 	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:191)
> 	... 9 more
> Caused by: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVersionedVaultContent(PicketBoxSecurityVault.java:609)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:480)
> 	... 11 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 08:07:00 2017
From: issues at jboss.org (Jan Pazdziora (JIRA))
Date: Wed, 22 Feb 2017 08:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8197) Following
 https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with
 wildfly-10.1.0-7.fc25.noarch fails
In-Reply-To: <JIRA.12678302.1487768181000@Atlassian.JIRA>
References: <JIRA.12678302.1487768181000@Atlassian.JIRA>
	<JIRA.12678302.1487768181000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678302.1487768181000.63233.1487768820417@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367497#comment-13367497 ] 

Jan Pazdziora commented on WFLY-8197:
-------------------------------------

https://bugzilla.redhat.com/show_bug.cgi?id=1165743#c7 suggests the (default) JKS + VAULT.dat are not supported. The question is if something (vault.sh?) should do the conversion from JKS to JCEKS or if the keytool parameters should specify JCEKS in the first place.

> Following https://github.com/wildfly/quickstart/tree/10.x/security-vault-askpass with wildfly-10.1.0-7.fc25.noarch fails
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8197
>                 URL: https://issues.jboss.org/browse/WFLY-8197
>             Project: WildFly
>          Issue Type: Bug
>         Environment: wildfly-10.1.0-7.fc25.noarch
>            Reporter: Jan Pazdziora
>            Assignee: Jason Greene
>            Priority: Trivial
>
> I try to follow the README in this quickstart but the parameters to the keytool command seem to create keystore which vault.sh does not like, resulting in
> {noformat}
> Problem occurred:
> java.lang.Exception: WFLYSEC0045: Exception encountered:
> 	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:194)
> 	at org.jboss.as.security.vault.VaultSession.startVaultSession(VaultSession.java:212)
> 	at org.jboss.as.security.vault.VaultTool.execute(VaultTool.java:193)
> 	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:83)
> 	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:330)
> 	at org.jboss.modules.Main.main(Main.java:505)
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:487)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:214)
> 	at org.jboss.as.security.vault.VaultSession.initSecurityVault(VaultSession.java:191)
> 	... 9 more
> Caused by: java.lang.RuntimeException: PBOX00137: Security Vault does not contain SecretKey entry under alias (vault)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVersionedVaultContent(PicketBoxSecurityVault.java:609)
> 	at org.picketbox.plugins.vault.PicketBoxSecurityVault.readVaultContent(PicketBoxSecurityVault.java:480)
> 	... 11 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 08:12:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8198) Shift WFLY-3858 solution to
 something driven by capabilities
In-Reply-To: <JIRA.12678310.1487769118000@Atlassian.JIRA>
References: <JIRA.12678310.1487769118000@Atlassian.JIRA>
	<JIRA.12678310.1487769118401@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678310.1487769118000.63300.1487769120988@Atlassian.JIRA>

Brian Stansberry created WFLY-8198:
--------------------------------------

             Summary: Shift WFLY-3858 solution to something driven by capabilities
                 Key: WFLY-8198
                 URL: https://issues.jboss.org/browse/WFLY-8198
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Brian Stansberry


Something for 12.

The proposed WFLY-3858 fix using a check of the infinispan subsystem model and a hard coded service name to control wiring. It be driven by capabilities.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 08:13:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8199) CS tool,
	log exception on error
In-Reply-To: <JIRA.12678311.1487769144000@Atlassian.JIRA>
References: <JIRA.12678311.1487769144000@Atlassian.JIRA>
	<JIRA.12678311.1487769144711@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678311.1487769144000.63309.1487769180430@Atlassian.JIRA>

Martin Choma created WFLY-8199:
----------------------------------

             Summary: CS tool, log exception on error
                 Key: WFLY-8199
                 URL: https://issues.jboss.org/browse/WFLY-8199
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


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  Wed Feb 22 08:32:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8200) CS tool,
 invalid content of --type parameter leads to NPE
In-Reply-To: <JIRA.12678313.1487770304000@Atlassian.JIRA>
References: <JIRA.12678313.1487770304000@Atlassian.JIRA>
	<JIRA.12678313.1487770304352@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678313.1487770304000.63518.1487770320905@Atlassian.JIRA>

Martin Choma created WFLY-8200:
----------------------------------

             Summary: CS tool, invalid content of --type parameter leads to NPE
                 Key: WFLY-8200
                 URL: https://issues.jboss.org/browse/WFLY-8200
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


If I fill {{-t,--type arg        Credential store type}} 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.<init>(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 Feb 22 08:33:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 08:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8198) Shift WFLY-3858 solution to
 something driven by capabilities
In-Reply-To: <JIRA.12678310.1487769118000@Atlassian.JIRA>
References: <JIRA.12678310.1487769118000@Atlassian.JIRA>
	<JIRA.12678310.1487769118000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678310.1487769118000.63528.1487770381051@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8198:
-----------------------------------
    Description: 
Something for 12.

The proposed WFLY-3858 fix is using a check of the infinispan subsystem model and a hard coded service name to control wiring. It should be driven by capabilities.

  was:
Something for 12.

The proposed WFLY-3858 fix using a check of the infinispan subsystem model and a hard coded service name to control wiring. It be driven by capabilities.



> Shift WFLY-3858 solution to something driven by capabilities
> ------------------------------------------------------------
>
>                 Key: WFLY-8198
>                 URL: https://issues.jboss.org/browse/WFLY-8198
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Brian Stansberry
>
> Something for 12.
> The proposed WFLY-3858 fix is using a check of the infinispan subsystem model and a hard coded service name to control wiring. It should be driven by capabilities.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 08:33:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 08:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8200) CS tool,
 invalid content of --type parameter leads to NPE
In-Reply-To: <JIRA.12678313.1487770304000@Atlassian.JIRA>
References: <JIRA.12678313.1487770304000@Atlassian.JIRA>
	<JIRA.12678313.1487770304000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678313.1487770304000.63534.1487770381217@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8200:
-------------------------------
    Description: 
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.<init>(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}


  was:
If I fill {{-t,--type arg        Credential store type}} 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.<init>(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}




> CS tool, invalid content of --type parameter leads to NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-8200
>                 URL: https://issues.jboss.org/browse/WFLY-8200
>             Project: WildFly
>          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.<init>(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 Feb 22 08:34:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 22 Feb 2017 08:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-835) SecurityIdentity Automatic
	Outflow
In-Reply-To: <JIRA.12667816.1481802782000@Atlassian.JIRA>
References: <JIRA.12667816.1481802782000@Atlassian.JIRA>
	<JIRA.12667816.1481802782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667816.1481802782000.63554.1487770440239@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367520#comment-13367520 ] 

Ondrej Lukas commented on ELY-835:
----------------------------------

[~dlofthouse] could you please create the RFE for this new functionality? Or in case if it is only subset of any existing RFE, then could you please add information to related Analysis Document? This information is required for preparing test plan as well as for covering this feature in documentation.

> SecurityIdentity Automatic Outflow
> ----------------------------------
>
>                 Key: ELY-835
>                 URL: https://issues.jboss.org/browse/ELY-835
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta24
>
>
> We previously discussed that when runAs is called on a SecurityIdentity this should pro-actively outflow to predefined security domains (which it has in trusted-security-domains?) so it does not need to be manually inflowed at a later point.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 08:46:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 22 Feb 2017 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7778) Remoting identity propagation
 does not work with Elytron
In-Reply-To: <JIRA.12666827.1481321898000@Atlassian.JIRA>
References: <JIRA.12666827.1481321898000@Atlassian.JIRA>
	<JIRA.12666827.1481321898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666827.1481321898000.63683.1487771160615@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7778:
-----------------------------
    Steps to Reproduce: 
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)

  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.testAuthentication()
org.jboss.as.test.integration.ejb.security.testAuthentication_BadPwd()
org.jboss.as.test.integration.ejb.security.testAuthentication_TwoBeans()
org.jboss.as.test.integration.ejb.security.testAuthentication_TwoBeans_ReAuth_BadPwd()
(and a lot of other, most of tests using EJB)



> Remoting 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 Feb 22 08:57:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8201) CS tool,
 missing parameters compared to management API
In-Reply-To: <JIRA.12678316.1487771778000@Atlassian.JIRA>
References: <JIRA.12678316.1487771778000@Atlassian.JIRA>
	<JIRA.12678316.1487771778079@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678316.1487771778000.63792.1487771820654@Atlassian.JIRA>

Martin Choma created WFLY-8201:
----------------------------------

             Summary: CS tool, missing parameters compared to management API
                 Key: WFLY-8201
                 URL: https://issues.jboss.org/browse/WFLY-8201
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Critical


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  Wed Feb 22 09:01:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 09:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.63869.1487772060538@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367547#comment-13367547 ] 

Brian Stansberry commented on WFLY-8141:
----------------------------------------

[~simkam] Good question. My meaning in any mention of the add op is that all the valid parameter combinations work as before. Similarly, for write-attribute, all the attributes that have been writable are still writable.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:10:01 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 09:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8202) CS tool,
	format Missing required option
In-Reply-To: <JIRA.12678321.1487772563000@Atlassian.JIRA>
References: <JIRA.12678321.1487772563000@Atlassian.JIRA>
	<JIRA.12678321.1487772563947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678321.1487772563000.63955.1487772601513@Atlassian.JIRA>

Martin Choma created WFLY-8202:
----------------------------------

             Summary: 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: Darran Lofthouse


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 Feb 22 09:10:02 2017
From: issues at jboss.org (Artemy Osipov (JIRA))
Date: Wed, 22 Feb 2017 09:10:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8203) Expose number of busy threads
 in the worker pool via JMX
In-Reply-To: <JIRA.12678322.1487772572000@Atlassian.JIRA>
References: <JIRA.12678322.1487772572000@Atlassian.JIRA>
	<JIRA.12678322.1487772572629@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678322.1487772572000.63961.1487772602265@Atlassian.JIRA>

Artemy Osipov created WFLY-8203:
-----------------------------------

             Summary: Expose number of busy threads in the worker pool via JMX
                 Key: WFLY-8203
                 URL: https://issues.jboss.org/browse/WFLY-8203
             Project: WildFly
          Issue Type: Feature Request
    Affects Versions: 10.1.0.Final
            Reporter: Artemy Osipov
            Assignee: Jason Greene


In org.xnio:type=Xnio,provider="nio",worker="default JMX only expose MaxWorkerPoolSize but not current value of number of busy threads in the worker pool. This metric will help in monitoring the server and its loading.
Max size of worker pool configured in IO subsystem.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:10:03 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 22 Feb 2017 09:10:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8202) CS tool,
	format Missing required option
In-Reply-To: <JIRA.12678321.1487772564000@Atlassian.JIRA>
References: <JIRA.12678321.1487772564000@Atlassian.JIRA>
	<JIRA.12678321.1487772564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678321.1487772564000.63980.1487772603301@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated WFLY-8202:
-------------------------------
    Labels: credential-store user_experience wildfly-elytron-tool  (was: credential-store wildfly-elytron-tool)


> 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: Darran Lofthouse
>              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 Feb 22 09:11:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 22 Feb 2017 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8204) work-manager and
 distributed-workmanager need an Elytron-enabled flag
In-Reply-To: <JIRA.12678325.1487772657000@Atlassian.JIRA>
References: <JIRA.12678325.1487772657000@Atlassian.JIRA>
	<JIRA.12678325.1487772657554@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678325.1487772657000.63992.1487772660617@Atlassian.JIRA>

Stefano Maestri created WFLY-8204:
-------------------------------------

             Summary: work-manager and distributed-workmanager need an Elytron-enabled flag
                 Key: WFLY-8204
                 URL: https://issues.jboss.org/browse/WFLY-8204
             Project: WildFly
          Issue Type: Bug
            Reporter: Stefano Maestri
            Assignee: Jason Greene
            Priority: Blocker


2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has  ElytronEnabled==false. We have a problem in this line:
https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L676

When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely.
I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:12:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 22 Feb 2017 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8204) work-manager and
 distributed-workmanager need an Elytron-enabled flag
In-Reply-To: <JIRA.12678325.1487772658000@Atlassian.JIRA>
References: <JIRA.12678325.1487772658000@Atlassian.JIRA>
	<JIRA.12678325.1487772658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678325.1487772658000.64004.1487772720928@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri reassigned WFLY-8204:
-------------------------------------

    Assignee: Flavia Rainone  (was: Jason Greene)


> work-manager and distributed-workmanager need an Elytron-enabled flag
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8204
>                 URL: https://issues.jboss.org/browse/WFLY-8204
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Stefano Maestri
>            Assignee: Flavia Rainone
>            Priority: Blocker
>
> 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has  ElytronEnabled==false. We have a problem in this line:
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L676
> When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely.
> I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:12:01 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 22 Feb 2017 09:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8204) work-manager and
 distributed-workmanager need an Elytron-enabled flag
In-Reply-To: <JIRA.12678325.1487772658000@Atlassian.JIRA>
References: <JIRA.12678325.1487772658000@Atlassian.JIRA>
	<JIRA.12678325.1487772658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678325.1487772658000.64009.1487772721083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri updated WFLY-8204:
----------------------------------
    Component/s: JCA


> work-manager and distributed-workmanager need an Elytron-enabled flag
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8204
>                 URL: https://issues.jboss.org/browse/WFLY-8204
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Flavia Rainone
>            Priority: Blocker
>
> 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has  ElytronEnabled==false. We have a problem in this line:
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L676
> When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely.
> I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:12:01 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 22 Feb 2017 09:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8204) work-manager and
 distributed-workmanager need an Elytron-enabled flag
In-Reply-To: <JIRA.12678325.1487772658000@Atlassian.JIRA>
References: <JIRA.12678325.1487772658000@Atlassian.JIRA>
	<JIRA.12678325.1487772658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678325.1487772658000.64031.1487772721970@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri updated WFLY-8204:
----------------------------------
    Labels: elytron_integration  (was: )


> work-manager and distributed-workmanager need an Elytron-enabled flag
> ---------------------------------------------------------------------
>
>                 Key: WFLY-8204
>                 URL: https://issues.jboss.org/browse/WFLY-8204
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Flavia Rainone
>            Priority: Blocker
>              Labels: elytron_integration
>
> 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has  ElytronEnabled==false. We have a problem in this line:
> https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L676
> When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely.
> I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:32:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Wed, 22 Feb 2017 09:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8205) work-manager and
 distributed-workmanager need an Elytron-enabled flag
In-Reply-To: <JIRA.12678330.1487773879000@Atlassian.JIRA>
References: <JIRA.12678330.1487773879000@Atlassian.JIRA>
	<JIRA.12678330.1487773879903@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678330.1487773879000.64278.1487773920359@Atlassian.JIRA>

Martin Simka created WFLY-8205:
----------------------------------

             Summary: work-manager and distributed-workmanager need an Elytron-enabled flag
                 Key: WFLY-8205
                 URL: https://issues.jboss.org/browse/WFLY-8205
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Martin Simka
            Assignee: Flavia Rainone
            Priority: Blocker


2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has  ElytronEnabled==false. We have a problem in this line:
https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/resourceadapters/deployment/AbstractResourceAdapterDeploymentService.java#L676

When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely.
I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 09:33:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Wed, 22 Feb 2017 09:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation excepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.64299.1487773980532@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367581#comment-13367581 ] 

Stefano Maestri commented on WFLY-8141:
---------------------------------------

[~brian.stansberry] I haven't any objection. o ahead, and let me know if/how I can help you.

> CachedConnectionManager add operation excepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 10:04:00 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Wed, 22 Feb 2017 10:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775791000@Atlassian.JIRA>
References: <JIRA.12678336.1487775791000@Atlassian.JIRA>
	<JIRA.12678336.1487775791859@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775791000.64576.1487775840498@Atlassian.JIRA>

Michal Petrov created WFCORE-2317:
-------------------------------------

             Summary: 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: Brian Stansberry


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  Wed Feb 22 10:09:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 22 Feb 2017 10:09:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8183) Anonymous Elytron SASL
 authentication fails for JMS
In-Reply-To: <JIRA.12678207.1487712320000@Atlassian.JIRA>
References: <JIRA.12678207.1487712320000@Atlassian.JIRA>
	<JIRA.12678207.1487712320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678207.1487712320000.64653.1487776141033@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil resolved WFLY-8183.
-------------------------------
    Resolution: Duplicate Issue


> Anonymous Elytron SASL authentication fails for JMS
> ---------------------------------------------------
>
>                 Key: WFLY-8183
>                 URL: https://issues.jboss.org/browse/WFLY-8183
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Josef Cacek
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> Anonymous JMS client access is not possible with Elytron.
> When the ANONYMOUS SASL mechanism is configured, then creating A-MQ session fails with:
> {code}
> 22:06:26,119 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: java.lang.IllegalArgumentException: Parameter 'guess' may not be null
> 	at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70)
> 	at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48)
> 	at org.wildfly.security.evidence.PasswordGuessEvidence.<init>(PasswordGuessEvidence.java:40)
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:87)
> 	at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62)
> 	at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132)
> 	at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:627)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
> 	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 11:22:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 22 Feb 2017 11:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.65268.1487780520450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367664#comment-13367664 ] 

Jan Kalina commented on WFLY-7322:
----------------------------------

Should be resolved after merging of ELY-971

> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 12:23:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Feb 2017 12:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8206) Add Elytron SecurityIdentity
 support to EE ContextServiceImpl
In-Reply-To: <JIRA.12678364.1487784133000@Atlassian.JIRA>
References: <JIRA.12678364.1487784133000@Atlassian.JIRA>
	<JIRA.12678364.1487784133906@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678364.1487784133000.65594.1487784180313@Atlassian.JIRA>

Darran Lofthouse created WFLY-8206:
--------------------------------------

             Summary: Add Elytron SecurityIdentity support to EE ContextServiceImpl
                 Key: WFLY-8206
                 URL: https://issues.jboss.org/browse/WFLY-8206
             Project: WildFly
          Issue Type: Task
          Components: EE, 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  Wed Feb 22 13:16:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 22 Feb 2017 13:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7778) Remoting identity propagation
 does not work with Elytron
In-Reply-To: <JIRA.12666827.1481321898000@Atlassian.JIRA>
References: <JIRA.12666827.1481321898000@Atlassian.JIRA>
	<JIRA.12666827.1481321898000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666827.1481321898000.65807.1487787360318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7778:
-----------------------------
    Steps to Reproduce: 
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()

  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)



> Remoting 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 Feb 22 13:39:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Wed, 22 Feb 2017 13:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-11) Create a simple web page
In-Reply-To: <JIRA.12678374.1487788738000@Atlassian.JIRA>
References: <JIRA.12678374.1487788738000@Atlassian.JIRA>
	<JIRA.12678374.1487788738880@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678374.1487788738000.65856.1487788740168@Atlassian.JIRA>

Luis Barreiro created AG-11:
-------------------------------

             Summary: Create a simple web page
                 Key: AG-11
                 URL: https://issues.jboss.org/browse/AG-11
             Project: Agroal
          Issue Type: Task
          Components: web
    Affects Versions: 0.1
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
             Fix For: 0.2


Using GitHub pages



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 14:31:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 22 Feb 2017 14:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8207) Upgrade JGroups to 4.0
In-Reply-To: <JIRA.12678377.1487791832000@Atlassian.JIRA>
References: <JIRA.12678377.1487791832000@Atlassian.JIRA>
	<JIRA.12678377.1487791832548@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678377.1487791832000.65961.1487791860205@Atlassian.JIRA>

Radoslav Husar created WFLY-8207:
------------------------------------

             Summary: Upgrade JGroups to 4.0
                 Key: WFLY-8207
                 URL: https://issues.jboss.org/browse/WFLY-8207
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro


Final of 4.0 just out:

http://belaban.blogspot.cz/2017/02/jgroups-400final.html



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 14:46:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 22 Feb 2017 14:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1448) [XLS Decision Table]
 Integer values for Double attributes causes validation error
In-Reply-To: <JIRA.12674317.1486026902000@Atlassian.JIRA>
References: <JIRA.12674317.1486026902000@Atlassian.JIRA>
	<JIRA.12674317.1486026902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674317.1486026902000.65994.1487792760386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved GUVNOR-2875 to DROOLS-1448:
------------------------------------------------

              Project: Drools  (was: Guvnor)
                  Key: DROOLS-1448  (was: GUVNOR-2875)
             Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Affects Version/s: 7.0.0.Beta6
                           (was: drools_7.0.0.Beta6)


> [XLS Decision Table] Integer values for Double attributes causes validation error
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-1448
>                 URL: https://issues.jboss.org/browse/DROOLS-1448
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: dtable_testday_preparation, qe-test-day, reported-by-qe
>         Attachments: Driver.java, ExamplePolicyPricing.xls, Policy.java, Screenshot from 2017-02-02 10-22-21.png
>
>
> If the XLS decision contains Integer values for column ( attribute ) that is Double data type, then the XLS decision table is not validated successfully. After conversion to guided decision table is the table validated successfully.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 14:50:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 22 Feb 2017 14:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1448) [XLS Decision Table]
 Integer values for Double attributes causes validation error
In-Reply-To: <JIRA.12674317.1486026902000@Atlassian.JIRA>
References: <JIRA.12674317.1486026902000@Atlassian.JIRA>
	<JIRA.12674317.1486026902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674317.1486026902000.66010.1487793000095@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367748#comment-13367748 ] 

Michael Anstis commented on DROOLS-1448:
----------------------------------------

The problem has nothing to do with the Workbench; compilation of the attached XLS file fails due to use of an {{int}} literal on a {{double}} field.

"Rule Compilation error The method setBasePrice(Double) in the type Policy is not applicable for the arguments (int)"

> [XLS Decision Table] Integer values for Double attributes causes validation error
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-1448
>                 URL: https://issues.jboss.org/browse/DROOLS-1448
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: dtable_testday_preparation, qe-test-day, reported-by-qe
>         Attachments: Driver.java, ExamplePolicyPricing.xls, Policy.java, Screenshot from 2017-02-02 10-22-21.png
>
>
> If the XLS decision contains Integer values for column ( attribute ) that is Double data type, then the XLS decision table is not validated successfully. After conversion to guided decision table is the table validated successfully.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 14:51:00 2017
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 22 Feb 2017 14:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1448) [XLS Decision Table]
 Integer values for Double attributes causes validation error
In-Reply-To: <JIRA.12674317.1486026902000@Atlassian.JIRA>
References: <JIRA.12674317.1486026902000@Atlassian.JIRA>
	<JIRA.12674317.1486026902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674317.1486026902000.66015.1487793060181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-1448:
--------------------------------------

    Assignee: Mario Fusco  (was: Michael Anstis)


> [XLS Decision Table] Integer values for Double attributes causes validation error
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-1448
>                 URL: https://issues.jboss.org/browse/DROOLS-1448
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Jozef Marko
>            Assignee: Mario Fusco
>            Priority: Minor
>              Labels: dtable_testday_preparation, qe-test-day, reported-by-qe
>         Attachments: Driver.java, ExamplePolicyPricing.xls, Policy.java, Screenshot from 2017-02-02 10-22-21.png
>
>
> If the XLS decision contains Integer values for column ( attribute ) that is Double data type, then the XLS decision table is not validated successfully. After conversion to guided decision table is the table validated successfully.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 15:24:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 15:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.66176.1487795040275@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367765#comment-13367765 ] 

Brian Stansberry commented on WFCORE-2317:
------------------------------------------

ValidateModelStepHandler can deal with this while looping through the attributes by checking whether the AttributeDefinition is of type ObjectTypeAttributeDefinition, ObjectListAttributeDefinition or ObjectMapAttributeDefinition. For the latter two use the getValueType() method (needs to be public) to get the underlying ObjectTypeAttributeDefinition. Get to the "object type" ModelNode (either the attribute value itself, or elements in its list in the ObjectListAttributeDefinition case, or values in its map in the ObjectMapAttributeDefinition case) and perform the requires/alternatives validation on it using the ObjectTypeAttributeDefinition.  The requires validation can be easier than is done with the root attribute, as there is no need for the "attemptReadMissingAttributeValueFromHandler" stuff, since the entire attribute value has already been read.

The logic should recurse, to handle cases where complex attributes have other complex types as fields.

Failure messages will be a bit more complex as the message should use the . and [0] formatted path to the offending field, rather than simply using the attribute name.

Not

WFCORExxx: attributename is invalid in combination with [b, c]

But rather

WFCORExxx: attributename[].a is invalid in combination with [b, c]

> 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: Brian Stansberry
>
> 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  Wed Feb 22 15:32:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 15:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.66206.1487795520407@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367765#comment-13367765 ] 

Brian Stansberry edited comment on WFCORE-2317 at 2/22/17 3:31 PM:
-------------------------------------------------------------------

ValidateModelStepHandler can deal with this while looping through the attributes by checking whether the AttributeDefinition is of type ObjectTypeAttributeDefinition, ObjectListAttributeDefinition or ObjectMapAttributeDefinition. For the latter two use the getValueType() method (needs to be public) to get the underlying ObjectTypeAttributeDefinition. Get to the "object type" ModelNode (either the attribute value itself, or elements in its list in the ObjectListAttributeDefinition case, or values in its map in the ObjectMapAttributeDefinition case) and perform the requires/alternatives validation on it using the ObjectTypeAttributeDefinition.  The requires validation can be easier than is done with the root attribute, as there is no need for the "attemptReadMissingAttributeValueFromHandler" stuff, since the entire attribute value has already been read.

The logic should recurse, to handle cases where complex attributes have other complex types as fields.

Failure messages will be a bit more complex as the message should use the . and [0] formatted path to the offending field, rather than simply using the attribute name.

Not

WFCORExxx: attributename is invalid in combination with [b, c]

But rather

WFCORExxx: attributename[].a is invalid in combination with [b, c]

I believe the existing ControllerLogger methods to create the exceptions would still be usable; the only difference is the parameter values passed in.


was (Author: brian.stansberry):
ValidateModelStepHandler can deal with this while looping through the attributes by checking whether the AttributeDefinition is of type ObjectTypeAttributeDefinition, ObjectListAttributeDefinition or ObjectMapAttributeDefinition. For the latter two use the getValueType() method (needs to be public) to get the underlying ObjectTypeAttributeDefinition. Get to the "object type" ModelNode (either the attribute value itself, or elements in its list in the ObjectListAttributeDefinition case, or values in its map in the ObjectMapAttributeDefinition case) and perform the requires/alternatives validation on it using the ObjectTypeAttributeDefinition.  The requires validation can be easier than is done with the root attribute, as there is no need for the "attemptReadMissingAttributeValueFromHandler" stuff, since the entire attribute value has already been read.

The logic should recurse, to handle cases where complex attributes have other complex types as fields.

Failure messages will be a bit more complex as the message should use the . and [0] formatted path to the offending field, rather than simply using the attribute name.

Not

WFCORExxx: attributename is invalid in combination with [b, c]

But rather

WFCORExxx: attributename[].a is invalid in combination with [b, c]

> 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: Brian Stansberry
>
> 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  Wed Feb 22 15:47:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 15:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.66246.1487796420372@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2317:
----------------------------------------

    Fix Version/s: 3.0.0.Beta5
         Assignee:     (was: Brian Stansberry)


I'm scheduling this but unassigning it. It would be nice to fix in 3.0.0 but not critical. I'm scheduling it so it stays on the radar screen.

> 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
>             Fix For: 3.0.0.Beta5
>
>
> 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  Wed Feb 22 17:17:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 22 Feb 2017 17:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8208) Capture and use
 SecurityIdentity for tasks submitted to ManagedExecutorServiceImpl and
 ManagedScheduledExecutorServiceImpl
In-Reply-To: <JIRA.12678395.1487801803000@Atlassian.JIRA>
References: <JIRA.12678395.1487801803000@Atlassian.JIRA>
	<JIRA.12678395.1487801803055@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678395.1487801803000.66531.1487801820298@Atlassian.JIRA>

Darran Lofthouse created WFLY-8208:
--------------------------------------

             Summary: Capture and use SecurityIdentity for tasks submitted to ManagedExecutorServiceImpl and ManagedScheduledExecutorServiceImpl
                 Key: WFLY-8208
                 URL: https://issues.jboss.org/browse/WFLY-8208
             Project: WildFly
          Issue Type: Task
          Components: EE, 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  Wed Feb 22 20:47:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 20:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation accepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.67206.1487814420482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8141:
-----------------------------------
    Summary: CachedConnectionManager add operation accepts no parameters anymore  (was: CachedConnectionManager add operation excepts no parameters anymore)


> CachedConnectionManager add operation accepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 20:54:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 22 Feb 2017 20:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8141) CachedConnectionManager add
 operation accepts no parameters anymore
In-Reply-To: <JIRA.12677275.1487256399000@Atlassian.JIRA>
References: <JIRA.12677275.1487256399000@Atlassian.JIRA>
	<JIRA.12677275.1487256399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677275.1487256399000.67222.1487814840329@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13367827#comment-13367827 ] 

Brian Stansberry commented on WFLY-8141:
----------------------------------------

[~maeste] [~iweiss] PR is up at https://github.com/wildfly/wildfly/pull/9692

> CachedConnectionManager add operation accepts no parameters anymore
> -------------------------------------------------------------------
>
>                 Key: WFLY-8141
>                 URL: https://issues.jboss.org/browse/WFLY-8141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Fix for WFLY-2640 broke :add operation for cached-connection-manager
> scipts that do
> {noformat}
> /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> {noformat}
> /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true")
> {noformat}
> now fail with
> {{Operation 'add' does not expect any property.}}
> This breaks our quickstarts



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 22:26:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Feb 2017 22:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2318) Wildfly OpenSSL 1.0.0.Beta6
In-Reply-To: <JIRA.12678414.1487820355000@Atlassian.JIRA>
References: <JIRA.12678414.1487820355000@Atlassian.JIRA>
	<JIRA.12678414.1487820355822@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678414.1487820355000.67271.1487820360267@Atlassian.JIRA>

Stuart Douglas created WFCORE-2318:
--------------------------------------

             Summary: Wildfly OpenSSL 1.0.0.Beta6
                 Key: WFCORE-2318
                 URL: https://issues.jboss.org/browse/WFCORE-2318
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 23:00:00 2017
From: issues at jboss.org (John Hovell (JIRA))
Date: Wed, 22 Feb 2017 23:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8209) JAX-RS Executes resource
 method even when input validation fails
In-Reply-To: <JIRA.12678417.1487822386000@Atlassian.JIRA>
References: <JIRA.12678417.1487822386000@Atlassian.JIRA>
	<JIRA.12678417.1487822386829@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678417.1487822386000.67289.1487822400236@Atlassian.JIRA>

John Hovell created WFLY-8209:
---------------------------------

             Summary: JAX-RS Executes resource method even when input validation fails
                 Key: WFLY-8209
                 URL: https://issues.jboss.org/browse/WFLY-8209
             Project: WildFly
          Issue Type: Bug
          Components: REST
    Affects Versions: 10.1.0.Final
            Reporter: John Hovell
            Assignee: Stuart Douglas


I have created an example which is actually a fork of the Wildfly Swarm repo. I could re-create the example:

https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation (project in subfolder jaxrs/jaxrs-cdi). The tip of this branch shows it is working in WF 10.0. The commit earlier shows it broken in WF 10.1.

If a JAX-RS resource is defined as an interface with an implementation that doesn't have a single arg constructor, in WF 10.0 you had to work around the issue in a roundabout way by extending the Application class, using the BeanManager to get the actual bean (not the proxy) and register it with JAX-RS. This seemed to be the only solution as even if you made a bean with a @Produces method on a managed bean, Resteasy still wouldn't know how to construct the bean. You get a fairly generic error that Resteasy can't find a constructor for the implementation (not the interface). See error below.

Despite being roundabout, this worked. In WF 10.1 the behavior is very surprising in that it executes the resource method even though input validation failed, and then it returns a 400 with a validation message (as expected) but with the nasty side effect that the resource method was executed (and it may have crashed due to null pointers, in which case the user gets 500 instead of 400).

[pre]
2017-02-22 19:26:08,213 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 5) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	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: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
	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)
[pre]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 23:02:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Feb 2017 23:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8209) JAX-RS Executes resource
 method even when input validation fails
In-Reply-To: <JIRA.12678417.1487822387000@Atlassian.JIRA>
References: <JIRA.12678417.1487822387000@Atlassian.JIRA>
	<JIRA.12678417.1487822387000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678417.1487822387000.67297.1487822520854@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8209:
------------------------------------

    Assignee: Alessio Soldano  (was: Stuart Douglas)


> JAX-RS Executes resource method even when input validation fails
> ----------------------------------------------------------------
>
>                 Key: WFLY-8209
>                 URL: https://issues.jboss.org/browse/WFLY-8209
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 10.1.0.Final
>            Reporter: John Hovell
>            Assignee: Alessio Soldano
>
> I have created an example which is actually a fork of the Wildfly Swarm repo. I could re-create the example:
> https://github.com/jhovell/wildfly-swarm-examples/tree/jaxrs-validation (project in subfolder jaxrs/jaxrs-cdi). The tip of this branch shows it is working in WF 10.0. The commit earlier shows it broken in WF 10.1.
> If a JAX-RS resource is defined as an interface with an implementation that doesn't have a single arg constructor, in WF 10.0 you had to work around the issue in a roundabout way by extending the Application class, using the BeanManager to get the actual bean (not the proxy) and register it with JAX-RS. This seemed to be the only solution as even if you made a bean with a @Produces method on a managed bean, Resteasy still wouldn't know how to construct the bean. You get a fairly generic error that Resteasy can't find a constructor for the implementation (not the interface). See error below.
> Despite being roundabout, this worked. In WF 10.1 the behavior is very surprising in that it executes the resource method even though input validation failed, and then it returns a 400 with a validation message (as expected) but with the nasty side effect that the resource method was executed (and it may have crashed due to null pointers, in which case the user gets 500 instead of 400).
> [pre]
> 2017-02-22 19:26:08,213 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 5) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 	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: RESTEASY003190: Could not find constructor for class: org.wildfly.swarm.examples.jaxrs.cdi.api.EmployeeController
> 	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)
> [pre]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Feb 22 23:11:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 22 Feb 2017 23:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2319) Undertow 1.4.11.Final
In-Reply-To: <JIRA.12678418.1487823012000@Atlassian.JIRA>
References: <JIRA.12678418.1487823012000@Atlassian.JIRA>
	<JIRA.12678418.1487823012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678418.1487823012000.67326.1487823060134@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved UNDERTOW-1004 to WFCORE-2319:
--------------------------------------------------

    Project: WildFly Core  (was: Undertow)
        Key: WFCORE-2319  (was: UNDERTOW-1004)


> Undertow 1.4.11.Final
> ---------------------
>
>                 Key: WFCORE-2319
>                 URL: https://issues.jboss.org/browse/WFCORE-2319
>             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 Feb 23 03:28:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 23 Feb 2017 03:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8210) Implicit bean archive ID
 contains the absolute VFS path of the resource
In-Reply-To: <JIRA.12678437.1487838423000@Atlassian.JIRA>
References: <JIRA.12678437.1487838423000@Atlassian.JIRA>
	<JIRA.12678437.1487838423290@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678437.1487838423000.67678.1487838480506@Atlassian.JIRA>

Martin Kouba created WFLY-8210:
----------------------------------

             Summary: Implicit bean archive ID contains the absolute VFS path of the resource
                 Key: WFLY-8210
                 URL: https://issues.jboss.org/browse/WFLY-8210
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 10.1.0.Final
            Reporter: Martin Kouba
            Assignee: Stuart Douglas


This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract. As a result, clustering does not work on Windows machines - see also JBEAP-8451. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 03:28:01 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 23 Feb 2017 03:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8210) Implicit bean archive ID
 contains the absolute VFS path of the resource
In-Reply-To: <JIRA.12678437.1487838423000@Atlassian.JIRA>
References: <JIRA.12678437.1487838423000@Atlassian.JIRA>
	<JIRA.12678437.1487838423000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678437.1487838423000.67692.1487838481112@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned WFLY-8210:
----------------------------------

    Assignee: Martin Kouba  (was: Stuart Douglas)


> Implicit bean archive ID contains the absolute VFS path of the resource
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8210
>                 URL: https://issues.jboss.org/browse/WFLY-8210
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>
> This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract. As a result, clustering does not work on Windows machines - see also JBEAP-8451. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 03:38:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 23 Feb 2017 03:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8210) Implicit bean archive ID
 contains the absolute VFS path of the resource
In-Reply-To: <JIRA.12678437.1487838423000@Atlassian.JIRA>
References: <JIRA.12678437.1487838423000@Atlassian.JIRA>
	<JIRA.12678437.1487838423000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678437.1487838423000.67729.1487839080297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-8210:
-------------------------------
    Fix Version/s: 11.0.0.Alpha1


> Implicit bean archive ID contains the absolute VFS path of the resource
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8210
>                 URL: https://issues.jboss.org/browse/WFLY-8210
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Kouba
>            Assignee: Martin Kouba
>             Fix For: 11.0.0.Alpha1
>
>
> This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract. As a result, clustering does not work on Windows machines - see also JBEAP-8451. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 04:15:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 23 Feb 2017 04:15:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8211) Upgrade Artemis
	1.5.3.jbossorg-003
In-Reply-To: <JIRA.12678446.1487841258000@Atlassian.JIRA>
References: <JIRA.12678446.1487841258000@Atlassian.JIRA>
	<JIRA.12678446.1487841258000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678446.1487841258000.67941.1487841301962@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-9054 to WFLY-8211:
------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8211  (was: JBEAP-9054)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: JMS
                     (was: ActiveMQ)
                     (was: JMS)


> Upgrade Artemis 1.5.3.jbossorg-003
> ----------------------------------
>
>                 Key: WFLY-8211
>                 URL: https://issues.jboss.org/browse/WFLY-8211
>             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 Feb 23 04:27:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Thu, 23 Feb 2017 04:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8212) Datasources subsystem - minor
 documentation enhancement in scheme file
In-Reply-To: <JIRA.12678447.1487841866000@Atlassian.JIRA>
References: <JIRA.12678447.1487841866000@Atlassian.JIRA>
	<JIRA.12678447.1487841866000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678447.1487841866000.68064.1487842020189@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-9055 to WFLY-8212:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8212  (was: JBEAP-9055)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                           (was: JCA)
                           (was: User Experience)
    Affects Version/s:     (was: 7.1.0.DR9)


> Datasources subsystem - minor documentation enhancement in scheme file
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8212
>                 URL: https://issues.jboss.org/browse/WFLY-8212
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: user_experience
>
> In the schema file {{docs/schema/wildfly-datasources_4_0.xsd}} there is a wrong word order in the {{fair}} element documentation in the complex type {{poolType}}.
> "Defines if pool should use be fair" -> "Defines if pool use should be fair".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:05:02 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 23 Feb 2017 05:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8213) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263440@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.68401.1487844302161@Atlassian.JIRA>

Jan Tymel created WFLY-8213:
-------------------------------

             Summary: Unable to start Slave host after Master was restarted with enabled RBAC
                 Key: WFLY-8213
                 URL: https://issues.jboss.org/browse/WFLY-8213
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Jan Tymel
            Assignee: Brian Stansberry
            Priority: Blocker


It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:

{code}
[Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
[Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>

(...)

Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
[Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
[Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
{code}

On master instance is given following output after a while:
{code}
[Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
[Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
{code}

Once the slave instance has been shut down, it is not possible to start it again. See following output:
{code}
[Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
[Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
[Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
[Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
[Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
[Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
[Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
[Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
[Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Host Controller] 	at java.lang.Thread.run(Thread.java:745)
[Host Controller] 
[Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
[Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
[Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
[Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
{code}

Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:05:02 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 23 Feb 2017 05:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8213) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.68412.1487844302566@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reassigned WFLY-8213:
-------------------------------

    Assignee:     (was: Brian Stansberry)


> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8213
>                 URL: https://issues.jboss.org/browse/WFLY-8213
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:05:03 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Thu, 23 Feb 2017 05:05:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8213) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.68429.1487844303182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFLY-8213:
----------------------------
    Steps to Reproduce: 
2 instances of WildFly (master and slave)
# start master with _host-master.xml_: {{bin/domain.sh -Djboss.domain.base.dir=domain/ --host-config=host-master.xml}}
# change port number in <socket interface="management" port="${jboss.management.native.port:9999}"/> in _host-slave.xml_ on slave instance in order to avoid port conflict (e.g. to 19999)
# start slave with _host-slave.xml_: {{bin/domain.sh -Djboss.domain.base.dir=domain/ --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1}}
# enable RBAC: {{/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)}}
# reload servers: {{:reload-servers}}
# shut down master
# start master again
# (optionally) shut down and start slave as well

  was:
2 instances of EAP (master and slave)
# start master with _host-master.xml_: {{bin/domain.sh -Djboss.domain.base.dir=domain/ --host-config=host-master.xml}}
# change port number in <socket interface="management" port="${jboss.management.native.port:9999}"/> in _host-slave.xml_ on slave instance in order to avoid port conflict (e.g. to 19999)
# start slave with _host-slave.xml_: {{bin/domain.sh -Djboss.domain.base.dir=domain/ --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1}}
# enable RBAC: {{/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)}}
# reload servers: {{:reload-servers}}
# shut down master
# start master again
# (optionally) shut down and start slave as well



> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8213
>                 URL: https://issues.jboss.org/browse/WFLY-8213
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:08:01 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 23 Feb 2017 05:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-977) PLAIN mechanism does not work
 with WildFlyElytronProvider for AuthenticationConfiguration
In-Reply-To: <JIRA.12678461.1487844477000@Atlassian.JIRA>
References: <JIRA.12678461.1487844477000@Atlassian.JIRA>
	<JIRA.12678461.1487844477752@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678461.1487844477000.68472.1487844481315@Atlassian.JIRA>

Ondrej Lukas created ELY-977:
--------------------------------

             Summary: 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
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            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  Thu Feb 23 05:09:00 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 23 Feb 2017 05:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-977) PLAIN mechanism does not work
 with WildFlyElytronProvider for AuthenticationConfiguration
In-Reply-To: <JIRA.12678461.1487844478000@Atlassian.JIRA>
References: <JIRA.12678461.1487844478000@Atlassian.JIRA>
	<JIRA.12678461.1487844478000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678461.1487844478000.68479.1487844540406@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-977:
-----------------------------
    Affects Version/s: 1.1.0.Beta25


> 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: Darran Lofthouse
>            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  Thu Feb 23 05:17:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 23 Feb 2017 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8214) Implicit bean archive ID
 contains the absolute VFS path of the resource
In-Reply-To: <JIRA.12678463.1487844971000@Atlassian.JIRA>
References: <JIRA.12678463.1487844971000@Atlassian.JIRA>
	<JIRA.12678463.1487844971596@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678463.1487844971000.68563.1487845020435@Atlassian.JIRA>

Martin Kouba created WFLY-8214:
----------------------------------

             Summary: Implicit bean archive ID contains the absolute VFS path of the resource
                 Key: WFLY-8214
                 URL: https://issues.jboss.org/browse/WFLY-8214
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 10.1.0.Final
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 11.0.0.Alpha1


This does not match the {{org.jboss.weld.bootstrap.spi.BeanDeploymentArchive}} contract. As a result, clustering does not work on Windows machines - see also JBEAP-8451. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:17:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2320) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.68570.1487845020667@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse moved WFLY-8213 to WFCORE-2320:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2320  (was: WFLY-8213)
    Component/s: Domain Management
                 Security
                     (was: Domain Management)
                     (was: Security)


> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2320
>                 URL: https://issues.jboss.org/browse/WFCORE-2320
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 05:39:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 05:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329079@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.68767.1487846340225@Atlassian.JIRA>

Bela Ban created JGRP-2159:
------------------------------

             Summary: 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


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 Feb 23 05:40:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 05:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.68773.1487846400140@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2159:
---------------------------
    Attachment: discarded_delta_view.log


> 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 Feb 23 06:25:02 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Feb 2017 06:25:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7885) Persistent calendar timer
 force logging for each invocation if the deployed-class has changed
In-Reply-To: <JIRA.12671015.1484310939000@Atlassian.JIRA>
References: <JIRA.12671015.1484310939000@Atlassian.JIRA>
	<JIRA.12671015.1484310939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671015.1484310939000.69120.1487849102592@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368038#comment-13368038 ] 

RH Bugzilla Integration commented on WFLY-7885:
-----------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1413033|https://bugzilla.redhat.com/show_bug.cgi?id=1413033] from ON_QA to VERIFIED

> 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 Feb 23 06:31:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 06:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.69149.1487849460324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2159:
---------------------------

Workaround: {{GMS.use_delta_views="false"}}

> 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 Feb 23 06:55:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Feb 2017 06:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8215) Upgrade Infinispan to
	8.2.7.Final
In-Reply-To: <JIRA.12678499.1487850852000@Atlassian.JIRA>
References: <JIRA.12678499.1487850852000@Atlassian.JIRA>
	<JIRA.12678499.1487850852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678499.1487850852000.69300.1487850901129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-9066 to WFLY-8215:
---------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8215  (was: JBEAP-9066)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Clustering
                     (was: Clustering)


> Upgrade Infinispan to 8.2.7.Final
> ---------------------------------
>
>                 Key: WFLY-8215
>                 URL: https://issues.jboss.org/browse/WFLY-8215
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 06:56:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 06:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2160) Custom code to pick bind
	address
In-Reply-To: <JIRA.12678500.1487850933000@Atlassian.JIRA>
References: <JIRA.12678500.1487850933000@Atlassian.JIRA>
	<JIRA.12678500.1487850933683@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678500.1487850933000.69304.1487850960155@Atlassian.JIRA>

Bela Ban created JGRP-2160:
------------------------------

             Summary: 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.1, 4.0.1


Example:

{{bind_addr="custom:com.acme.BindAddressPicker"}}.

The fully qualified name of a class implementing {{Supplier<InetAddress>}} needs to be given after "custom:".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 06:57:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2160) Custom code to pick bind
	address
In-Reply-To: <JIRA.12678500.1487850934000@Atlassian.JIRA>
References: <JIRA.12678500.1487850934000@Atlassian.JIRA>
	<JIRA.12678500.1487850934000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678500.1487850934000.69316.1487851020807@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2160.
----------------------------
    Resolution: Done


> 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.1, 4.0.1
>
>
> Example:
> {{bind_addr="custom:com.acme.BindAddressPicker"}}.
> The fully qualified name of a class implementing {{Supplier<InetAddress>}} needs to be given after "custom:".



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 06:57:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Feb 2017 06:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8215) Upgrade Infinispan to
	8.2.7.Final
In-Reply-To: <JIRA.12678499.1487850852000@Atlassian.JIRA>
References: <JIRA.12678499.1487850852000@Atlassian.JIRA>
	<JIRA.12678499.1487850852000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678499.1487850852000.69326.1487851021137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8215:
---------------------------------
    Description: https://issues.jboss.org/projects/ISPN/versions/12333501


> Upgrade Infinispan to 8.2.7.Final
> ---------------------------------
>
>                 Key: WFLY-8215
>                 URL: https://issues.jboss.org/browse/WFLY-8215
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>
> https://issues.jboss.org/projects/ISPN/versions/12333501



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:08:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Feb 2017 07:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8216) Cannot Specify Attribute
 'cluster' Within The cache-container Configuration (EAP 7.0.2)
In-Reply-To: <JIRA.12678503.1487851616000@Atlassian.JIRA>
References: <JIRA.12678503.1487851616000@Atlassian.JIRA>
	<JIRA.12678503.1487851616000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678503.1487851616000.69762.1487851680675@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-9067 to WFLY-8216:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8216  (was: JBEAP-9067)
             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.0.2.GA)


> Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-8216
>                 URL: https://issues.jboss.org/browse/WFLY-8216
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>         Environment: Red Hat JBoss Enterprise Application Platform 7.0.2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> It seems that specifying the attribute 'cluster' within the cache-container configuration is no longer possible for EAP 7.0.2. With EAP 6.x, one could specify the 'cluster' attribute like such:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
>     <transport cluster="testname" lock-timeout="60000"/>
>     <replicated-cache name="repl" mode="ASYNC" batching="true">
>            <file-store/>
>      </replicated-cache>
> </cache-container>
> Resulting in the following (log):
> INFO  [stdout] (ServerService Thread Pool -- 58) GMS: address=rhel-box/testname, cluster=testname, physical address=127.0.0.1:55200
> ...
> 16:34:40,662 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000094: Received new cluster view: [rhel-box/testname|0] [rhel-box/testname]
> It seems that this functionality is no longer in EAP 7.x. Specifying the above results in parsing errors (although the attribute 'cluster' seems valid per the Infinispan xsd). 
> 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:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[224,17]
> Message: WFLYCTL0197: Unexpected attribute 'cluster' encountered
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseTransport(InfinispanSubsystemXMLReader.java:309)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:183)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:75)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:53)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:546)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:242)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> This also seems to be the case for the latest EAP 7.0.4 release.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:08:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Feb 2017 07:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8216) Cannot Specify Attribute
 'cluster' Within The cache-container Configuration (EAP 7.0.2)
In-Reply-To: <JIRA.12678503.1487851616000@Atlassian.JIRA>
References: <JIRA.12678503.1487851616000@Atlassian.JIRA>
	<JIRA.12678503.1487851616000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678503.1487851616000.69765.1487851680790@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8216:
---------------------------------
    Priority: Minor  (was: Major)


> Cannot Specify Attribute 'cluster' Within The cache-container Configuration (EAP 7.0.2)
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-8216
>                 URL: https://issues.jboss.org/browse/WFLY-8216
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>         Environment: Red Hat JBoss Enterprise Application Platform 7.0.2
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Minor
>
> It seems that specifying the attribute 'cluster' within the cache-container configuration is no longer possible for EAP 7.0.2. With EAP 6.x, one could specify the 'cluster' attribute like such:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
>     <transport cluster="testname" lock-timeout="60000"/>
>     <replicated-cache name="repl" mode="ASYNC" batching="true">
>            <file-store/>
>      </replicated-cache>
> </cache-container>
> Resulting in the following (log):
> INFO  [stdout] (ServerService Thread Pool -- 58) GMS: address=rhel-box/testname, cluster=testname, physical address=127.0.0.1:55200
> ...
> 16:34:40,662 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 58) ISPN000094: Received new cluster view: [rhel-box/testname|0] [rhel-box/testname]
> It seems that this functionality is no longer in EAP 7.x. Specifying the above results in parsing errors (although the attribute 'cluster' seems valid per the Infinispan xsd). 
> 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:131)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[224,17]
> Message: WFLYCTL0197: Unexpected attribute 'cluster' encountered
> 	at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseTransport(InfinispanSubsystemXMLReader.java:309)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:183)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:75)
> 	at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:53)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:546)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:242)
> 	at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:141)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:103)
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> 	... 3 more
> This also seems to be the case for the latest EAP 7.0.4 release.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:29:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Thu, 23 Feb 2017 07:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-38) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12677336.1487269840000@Atlassian.JIRA>
References: <JIRA.12677336.1487269840000@Atlassian.JIRA>
	<JIRA.12677336.1487269840000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677336.1487269840000.70004.1487852940587@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368088#comment-13368088 ] 

Prachi Yadav commented on HAWKULARQE-38:
----------------------------------------

Manual Test case created

https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10034

> Manual Testcases - Create and Run
> ---------------------------------
>
>                 Key: HAWKULARQE-38
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-38
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Prachi Yadav
>
> Create manual testcases if not exists.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:30:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Thu, 23 Feb 2017 07:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment
In-Reply-To: <JIRA.12677335.1487269804000@Atlassian.JIRA>
References: <JIRA.12677335.1487269804000@Atlassian.JIRA>
	<JIRA.12677335.1487269804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677335.1487269804000.70027.1487853000608@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368090#comment-13368090 ] 

Prachi Yadav commented on HAWKULARQE-37:
----------------------------------------

manual test case created

https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10034

> 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 Feb 23 07:30:00 2017
From: issues at jboss.org (Prachi Yadav (JIRA))
Date: Thu, 23 Feb 2017 07:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-39) Automate testcases
In-Reply-To: <JIRA.12677337.1487269868000@Atlassian.JIRA>
References: <JIRA.12677337.1487269868000@Atlassian.JIRA>
	<JIRA.12677337.1487269868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677337.1487269868000.70033.1487853000856@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Prachi Yadav reassigned HAWKULARQE-39:
--------------------------------------

    Assignee: Prachi Yadav  (was: mfoley user)


> Automate testcases
> ------------------
>
>                 Key: HAWKULARQE-39
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-39
>             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 Feb 23 07:41:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Thu, 23 Feb 2017 07:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-46) Agent starts the
 agentservice when an agent config is changed.
In-Reply-To: <JIRA.12678514.1487853620000@Atlassian.JIRA>
References: <JIRA.12678514.1487853620000@Atlassian.JIRA>
	<JIRA.12678514.1487853620610@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678514.1487853620000.70148.1487853660632@Atlassian.JIRA>

Matt Mahoney created HAWKULARQE-46:
--------------------------------------

             Summary: 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

Major change to wildfly agent internals - it now restarts the agent
service when an agent config is changed.

            Reporter: Matt Mahoney
            Assignee: mfoley user






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:42:00 2017
From: issues at jboss.org (Matt Mahoney (JIRA))
Date: Thu, 23 Feb 2017 07:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-46) Agent starts the
 agentservice when an agent config is changed.
In-Reply-To: <JIRA.12678514.1487853621000@Atlassian.JIRA>
References: <JIRA.12678514.1487853621000@Atlassian.JIRA>
	<JIRA.12678514.1487853621000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678514.1487853621000.70162.1487853720249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Mahoney updated HAWKULARQE-46:
-----------------------------------
    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.


  was:
>From hrupp Status 2/23/2017

Major change to wildfly agent internals - it now restarts the agent
service when an agent config is changed.




> 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: mfoley user
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 07:48:00 2017
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 23 Feb 2017 07:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2321)
 ProcessStateListenerTestCase from wf-core fails intermittently
In-Reply-To: <JIRA.12678516.1487854006000@Atlassian.JIRA>
References: <JIRA.12678516.1487854006000@Atlassian.JIRA>
	<JIRA.12678516.1487854006000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678516.1487854006000.70245.1487854080405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet moved JBEAP-9069 to WFCORE-2321:
--------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2321  (was: JBEAP-9069)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s: 3.0.0.Beta4
                           (was: 7.1.0.DR11)


> ProcessStateListenerTestCase from wf-core fails intermittently
> --------------------------------------------------------------
>
>                 Key: WFCORE-2321
>                 URL: https://issues.jboss.org/browse/WFCORE-2321
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.0.Beta4
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> org.jboss.as.test.integration.domain.events.ProcessStateListenerTestCase from wf-core fails intermittently on Windows
> *How reproducible:*
> 3%
> *Actual results:*
> StackTrace:
> {noformat}
> java.lang.AssertionError: Expected lines: [HOST_CONTROLLER normal ok stopping, HOST_CONTROLLER normal starting ok, HOST_CONTROLLER normal ok stopping] but was [HOST_CONTROLLER normal ok stopping, HOST_CONTROLLER normal starting stopping] expected:<3> but was:<2>
> 	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.jboss.as.test.integration.domain.events.ProcessStateListenerTestCase.checkLines(ProcessStateListenerTestCase.java:198)
> 	at org.jboss.as.test.integration.domain.events.ProcessStateListenerTestCase.doTestListenerServer(ProcessStateListenerTestCase.java:181)
> 	at org.jboss.as.test.integration.domain.events.ProcessStateListenerTestCase.testListenerOnHostController(ProcessStateListenerTestCase.java:117)
> {noformat}
> Standard output:
> {noformat}
> [Server:main-one] 04:25:29,349 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test-jmx-notifications-deployment.jar (runtime-name: test-jmx-notifications-deployment.jar) in 8ms
> [Server:main-one] 04:25:29,374 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 14) WFLYSRV0009: Undeployed "test-jmx-notifications-deployment.jar" (runtime-name: "test-jmx-notifications-deployment.jar")
> [Server:main-one] 04:25:29,380 INFO  [org.jboss.as.repository] (ServerService Thread Pool -- 14) WFLYDR0002: Content removed from location W:\workspace\eap-7x-as-testsuite-test-core-windows\8d745675\testsuite\domain\target\domains\JmxControlledStateNotificationsTestCase\master\servers\main-one\data\content\f3\d1f9875100d07edc87c90fd08c297797c34108\content
> [Host Controller] 04:25:29,410 INFO  [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location W:\workspace\eap-7x-as-testsuite-test-core-windows\8d745675\testsuite\domain\target\domains\JmxControlledStateNotificationsTestCase\master\data\content\f3\d1f9875100d07edc87c90fd08c297797c34108\content
> 04:25:36,309 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> 04:25:36,841 INFO  [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
> [Host Controller] 04:25:43,090 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> [Host Controller] 04:25:43,668 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Host Controller] 04:25:43,730 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Host Controller] 04:25:44,184 INFO  [org.jboss.as.domain.management] (Controller Boot Thread) WFLYDM0136: Registered OpenSSL provider
> [Host Controller] 04:25:44,420 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-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.
> [Host Controller] 04:25:44,422 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/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.
> [Host Controller] 04:25:44,530 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 04:25:44,536 INFO  [org.xnio] (MSC service thread 1-4) XNIO version 3.4.3.Final-redhat-1
> [Host Controller] 04:25:44,542 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.4.3.Final-redhat-1
> [Host Controller] 04:25:44,598 INFO  [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Host Controller] 04:25:44,674 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 5.0.0.Beta12-redhat-1
> [Host Controller] 04:25:44,696 INFO  [org.wildfly.security] (MSC service thread 1-4) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1
> [Host Controller] 04:25:44,755 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:9999
> [Host Controller] 04:25:44,785 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> [Host Controller] 04:25:45,252 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server main-one
> 04:25:45,266 INFO  [org.jboss.as.process.Server:main-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:main-one'
> [Server:main-one] 04:25:51,569 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> [Server:main-one] 04:25:52,175 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Server:main-one] 04:25:52,342 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Server:main-one] 04:25:52,404 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.4.3.Final-redhat-1
> [Server:main-one] 04:25:52,422 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.3.Final-redhat-1
> [Server:main-one] 04:25:52,619 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 5.0.0.Beta12-redhat-1
> [Server:main-one] 04:25:52,635 INFO  [org.wildfly.security] (MSC service thread 1-1) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1
> [Server:main-one] 04:25:52,816 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> [Host Controller] 04:25:53,187 INFO  [org.jboss.as.host.controller] (management task-8) WFLYHC0021: Server [Server:main-one] connected using connection [Channel ID 0fdf5dfd (inbound) of Remoting connection 06174798 to /127.0.0.1:65013 of endpoint "master:MANAGEMENT" <4315d93e>]
> [Host Controller] 04:25:53,218 INFO  [org.jboss.as.host.controller] (server-registration-threads - 1) WFLYHC0020: Registering server main-one
> [Host Controller] 04:25:53,231 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> [Host Controller] 04:25:53,231 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> [Host Controller] 04:25:53,231 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" (Host Controller) started in 10816ms - Started 50 of 50 services (13 services are lazy, passive or on-demand)
> INFO  [org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil] ServerIdentity{name=main-one, host=master, server-group=main-server-group} status is starting
> [Server:main-one] 04:25:53,597 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 13) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> [Server:main-one] 04:25:53,652 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Server:main-one] 04:25:53,769 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" started in 2933ms - Started 49 of 66 services (24 services are lazy, passive or on-demand)
> [Server:main-one] 04:25:53,771 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> INFO  [org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil] All servers started in 19286 ms
> INFO  [org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil] HostController started in 19539 ms
> [Host Controller] 04:25:54,228 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 13) WFLYHC0024: Stopping server main-one
> 04:25:54,231 INFO  [org.jboss.as.process.Server:main-one.status] (ProcessController-threads - 3) WFLYPC0019: Stopping process 'Server:main-one'
> [Server:main-one] 04:25:54,233 INFO  [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut down; shutting down
> [Host Controller] 04:25:54,257 INFO  [org.jboss.as.host.controller] (management task-6) WFLYHC0027: Unregistering server main-one
> [Server:main-one] 04:25:54,277 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" stopped in 31ms
> 04:25:54,640 INFO  [org.jboss.as.process.Server:main-one.status] (reaper for Server:main-one) WFLYPC0011: Process 'Server:main-one' finished with an exit status of 0
> [Host Controller] 04:25:54,642 INFO  [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server main-one
> [Host Controller] 04:25:54,659 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" stopped in 438ms
> [Host Controller] 04:25:54,662 INFO  [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Host Controller] 04:25:54,692 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-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.
> [Host Controller] 04:25:54,693 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/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.
> [Host Controller] 04:25:54,710 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 04:25:54,723 INFO  [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Host Controller] 04:25:54,736 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> [Host Controller] 04:25:54,738 INFO  [org.jboss.as.remoting] (MSC service thread 1-4) WFLYRMT0001: Listening on 127.0.0.1:9999
> [Host Controller] 04:25:54,859 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server main-one
> 04:25:54,872 INFO  [org.jboss.as.process.Server:main-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:main-one'
> [Server:main-one] 04:26:01,245 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> [Server:main-one] 04:26:01,817 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Server:main-one] 04:26:01,948 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Server:main-one] 04:26:02,062 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.4.3.Final-redhat-1
> [Server:main-one] 04:26:02,069 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.3.Final-redhat-1
> [Server:main-one] 04:26:02,287 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 5.0.0.Beta12-redhat-1
> [Server:main-one] 04:26:02,305 INFO  [org.wildfly.security] (MSC service thread 1-1) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1
> [Server:main-one] 04:26:02,485 INFO  [org.jboss.as.domain.management] (MSC service thread 1-3) WFLYDM0136: Registered OpenSSL provider
> [Host Controller] 04:26:02,828 INFO  [org.jboss.as.host.controller] (management task-6) WFLYHC0021: Server [Server:main-one] connected using connection [Channel ID 2fd5fab5 (inbound) of Remoting connection 7883e1b4 to /127.0.0.1:65044 of endpoint "master:MANAGEMENT" <7cbc6a7c>]
> [Host Controller] 04:26:02,836 INFO  [org.jboss.as.host.controller] (server-registration-threads - 1) WFLYHC0020: Registering server main-one
> [Server:main-one] 04:26:03,156 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 13) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> INFO  [org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil] ServerIdentity{name=main-one, host=master, server-group=main-server-group} status is starting
> [Server:main-one] 04:26:03,221 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Server:main-one] 04:26:03,384 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" started in 2948ms - Started 49 of 66 services (24 services are lazy, passive or on-demand)
> [Server:main-one] 04:26:03,385 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 8) WFLYSRV0212: Resuming server
> [Host Controller] 04:26:03,465 INFO  [org.jboss.as.host.controller] (management-handler-thread - 4) WFLYHC0180: Shutting down in response to management operation 'shutdown'
> 04:26:03,469 INFO  [org.jboss.as.process] (Thread-15) WFLYPC0017: Shutting down process controller
> 04:26:03,470 INFO  [org.jboss.as.process.Host Controller.status] (Thread-15) WFLYPC0019: Stopping process 'Host Controller'
> [Host Controller] 04:26:03,485 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 27) WFLYHC0024: Stopping server main-one
> 04:26:03,487 INFO  [org.jboss.as.process.Server:main-one.status] (ProcessController-threads - 3) WFLYPC0019: Stopping process 'Server:main-one'
> [Server:main-one] 04:26:03,489 INFO  [org.jboss.as.server] (main) WFLYSRV0240: ProcessController has signalled to shut down; shutting down
> [Host Controller] 04:26:03,522 INFO  [org.jboss.as.host.controller] (management task-2) WFLYHC0027: Unregistering server main-one
> [Server:main-one] 04:26:03,529 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" stopped in 21ms
> 04:26:03,897 INFO  [org.jboss.as.process.Server:main-one.status] (reaper for Server:main-one) WFLYPC0011: Process 'Server:main-one' finished with an exit status of 0
> [Host Controller] 04:26:03,898 INFO  [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server main-one
> 04:26:12,537 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> 04:26:13,096 INFO  [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
> [Host Controller] 04:26:19,971 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> [Host Controller] 04:26:20,519 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Host Controller] 04:26:20,575 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Host Controller] 04:26:20,997 INFO  [org.jboss.as.domain.management] (Controller Boot Thread) WFLYDM0136: Registered OpenSSL provider
> [Host Controller] 04:26:21,231 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/core-service=management/management-interface=native-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.
> [Host Controller] 04:26:21,233 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/host=master/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.
> [Host Controller] 04:26:21,351 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 04:26:21,418 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Host Controller] 04:26:21,426 INFO  [org.xnio] (MSC service thread 1-2) XNIO version 3.4.3.Final-redhat-1
> [Host Controller] 04:26:21,432 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.3.Final-redhat-1
> [Host Controller] 04:26:21,614 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 5.0.0.Beta12-redhat-1
> [Host Controller] 04:26:21,638 INFO  [org.wildfly.security] (MSC service thread 1-1) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1
> [Host Controller] 04:26:21,685 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) WFLYRMT0001: Listening on 127.0.0.1:9999
> [Host Controller] 04:26:21,710 WARN  [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-2) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> [Host Controller] 04:26:22,152 INFO  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server main-one
> 04:26:22,162 INFO  [org.jboss.as.process.Server:main-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:main-one'
> [Server:main-one] 04:26:28,565 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta4-redhat-1
> [Server:main-one] 04:26:29,158 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1-redhat-1
> [Server:main-one] 04:26:29,295 INFO  [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" starting
> [Server:main-one] 04:26:29,409 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.4.3.Final-redhat-1
> [Server:main-one] 04:26:29,419 INFO  [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.3.Final-redhat-1
> [Server:main-one] 04:26:29,605 INFO  [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 5.0.0.Beta12-redhat-1
> [Server:main-one] 04:26:29,624 INFO  [org.wildfly.security] (MSC service thread 1-1) ELY00001: WildFly Elytron version 1.1.0.Beta21-redhat-1
> [Server:main-one] 04:26:29,842 INFO  [org.jboss.as.domain.management] (MSC service thread 1-1) WFLYDM0136: Registered OpenSSL provider
> [Host Controller] 04:26:30,290 INFO  [org.jboss.as.host.controller] (management task-4) WFLYHC0021: Server [Server:main-one] connected using connection [Channel ID 604f0718 (inbound) of Remoting connection 28c687ba to /127.0.0.1:65081 of endpoint "master:MANAGEMENT" <2ca0b551>]
> [Host Controller] 04:26:30,357 INFO  [org.jboss.as.host.controller] (server-registration-threads - 1) WFLYHC0020: Registering server main-one
> [Host Controller] 04:26:30,421 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> [Host Controller] 04:26:30,421 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> [Host Controller] 04:26:30,422 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" (Host Controller) started in 11766ms - Started 50 of 50 services (13 services are lazy, passive or on-demand)
> [Server:main-one] 04:26:30,649 INFO  [org.wildfly.extension.io] (ServerService Thread Pool -- 13) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> [Server:main-one] 04:26:30,722 INFO  [org.jboss.as.patching] (MSC service thread 1-4) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> [Server:main-one] 04:26:30,797 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha22-redhat-1 "Kenny" started in 3014ms - Started 49 of 66 services (24 services are lazy, passive or on-demand)
> [Server:main-one] 04:26:30,804 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> {noformat}
> *Expected results:*
> No errors.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 08:03:00 2017
From: issues at jboss.org (Jappie Klooster (JIRA))
Date: Thu, 23 Feb 2017 08:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1449) Confusing error messages in
 certain combination of invalid type declerations/imports
In-Reply-To: <JIRA.12678520.1487854955000@Atlassian.JIRA>
References: <JIRA.12678520.1487854955000@Atlassian.JIRA>
	<JIRA.12678520.1487854955953@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678520.1487854955000.70508.1487854980719@Atlassian.JIRA>

Jappie Klooster created DROOLS-1449:
---------------------------------------

             Summary: Confusing error messages in certain combination of invalid type declerations/imports
                 Key: DROOLS-1449
                 URL: https://issues.jboss.org/browse/DROOLS-1449
             Project: Drools
          Issue Type: Feature Request
          Components: build, tools
    Affects Versions: 6.5.0.Final
            Reporter: Jappie Klooster
            Assignee: Petr ?irok?
            Priority: Minor


The following drools will make the error handling flip:

{code:drools}
package dialogue;

import java.util.Unkown

declare DefaultReply
	symbol:Unkown
end

{code}

Will result in:

[ERROR] Failed to execute goal org.kie:kie-maven-plugin:6.5.0.Final:build (default-build) on project salve_drools: Execution default-build of goal org.kie:kie-maven-plugin:6.5.0.Final:build failed: A required class was missing while executing org.kie:kie-maven-plugin:6.5.0.Final:build: Ljava/util/Unkown;
[ERROR] -----------------------------------------------------
[ERROR] realm =    extension>org.kie:kie-maven-plugin:6.5.0.Final
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/home/username/.m2/repository/org/kie/kie-maven-plugin/6.5.0.Final/kie-maven-plugin-6.5.0.Final.jar
[ERROR] urls[1] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
[ERROR] urls[2] = file:/home/username/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
[ERROR] urls[3] = file:/home/username/.m2/repository/javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.0-SP4.jar
[ERROR] urls[4] = file:/home/username/.m2/repository/org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.1_spec/1.0.1.Final/jboss-interceptors-api_1.1_spec-1.0.1.Final.jar
[ERROR] urls[5] = file:/home/username/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar
[ERROR] urls[6] = file:/home/username/.m2/repository/org/sonatype/sisu/sisu-guice/3.2.3/sisu-guice-3.2.3-no_aop.jar
[ERROR] urls[7] = file:/home/username/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar
[ERROR] urls[8] = file:/home/username/.m2/repository/com/google/guava/guava/13.0.1/guava-13.0.1.jar
[ERROR] urls[9] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar
[ERROR] urls[10] = file:/home/username/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[11] = file:/home/username/.m2/repository/org/sonatype/plexus/plexus-cipher/1.7/plexus-cipher-1.7.jar
[ERROR] urls[12] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[13] = file:/home/username/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar
[ERROR] urls[14] = file:/home/username/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
[ERROR] urls[15] = file:/home/username/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar
[ERROR] urls[16] = file:/home/username/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
[ERROR] urls[17] = file:/home/username/.m2/repository/junit/junit/4.12/junit-4.12.jar
[ERROR] urls[18] = file:/home/username/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] urls[19] = file:/home/username/.m2/repository/com/google/protobuf/protobuf-java/2.6.0/protobuf-java-2.6.0.jar
[ERROR] urls[20] = file:/home/username/.m2/repository/org/drools/drools-core/6.5.0.Final/drools-core-6.5.0.Final.jar
[ERROR] urls[21] = file:/home/username/.m2/repository/org/mvel/mvel2/2.2.8.Final/mvel2-2.2.8.Final.jar
[ERROR] urls[22] = file:/home/username/.m2/repository/commons-codec/commons-codec/1.4/commons-codec-1.4.jar
[ERROR] urls[23] = file:/home/username/.m2/repository/org/drools/drools-compiler/6.5.0.Final/drools-compiler-6.5.0.Final.jar
[ERROR] urls[24] = file:/home/username/.m2/repository/org/antlr/antlr-runtime/3.5/antlr-runtime-3.5.jar
[ERROR] urls[25] = file:/home/username/.m2/repository/org/eclipse/jdt/core/compiler/ecj/4.4.2/ecj-4.4.2.jar
[ERROR] urls[26] = file:/home/username/.m2/repository/com/thoughtworks/xstream/xstream/1.4.9/xstream-1.4.9.jar
[ERROR] urls[27] = file:/home/username/.m2/repository/xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1.jar
[ERROR] urls[28] = file:/home/username/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.jar
[ERROR] urls[29] = file:/home/username/.m2/repository/org/kie/kie-api/6.5.0.Final/kie-api-6.5.0.Final.jar
[ERROR] urls[30] = file:/home/username/.m2/repository/org/kie/kie-internal/6.5.0.Final/kie-internal-6.5.0.Final.jar
[ERROR] urls[31] = file:/home/username/.m2/repository/org/drools/drools-decisiontables/6.5.0.Final/drools-decisiontables-6.5.0.Final.jar
[ERROR] urls[32] = file:/home/username/.m2/repository/org/apache/poi/poi-ooxml/3.13/poi-ooxml-3.13.jar
[ERROR] urls[33] = file:/home/username/.m2/repository/org/apache/poi/poi-ooxml-schemas/3.13/poi-ooxml-schemas-3.13.jar
[ERROR] urls[34] = file:/home/username/.m2/repository/org/apache/xmlbeans/xmlbeans/2.3.0/xmlbeans-2.3.0.jar
[ERROR] urls[35] = file:/home/username/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar
[ERROR] urls[36] = file:/home/username/.m2/repository/org/apache/poi/poi/3.13/poi-3.13.jar
[ERROR] urls[37] = file:/home/username/.m2/repository/org/drools/drools-templates/6.5.0.Final/drools-templates-6.5.0.Final.jar
[ERROR] urls[38] = file:/home/username/.m2/repository/org/drools/drools-scorecards/6.5.0.Final/drools-scorecards-6.5.0.Final.jar
[ERROR] urls[39] = file:/home/username/.m2/repository/org/drools/drools-pmml/6.5.0.Final/drools-pmml-6.5.0.Final.jar
[ERROR] urls[40] = file:/home/username/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.11/jaxb-impl-2.2.11.jar
[ERROR] urls[41] = file:/home/username/.m2/repository/com/sun/xml/bind/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
[ERROR] urls[42] = file:/home/username/.m2/repository/org/jbpm/jbpm-bpmn2/6.5.0.Final/jbpm-bpmn2-6.5.0.Final.jar
[ERROR] urls[43] = file:/home/username/.m2/repository/org/jbpm/jbpm-flow-builder/6.5.0.Final/jbpm-flow-builder-6.5.0.Final.jar
[ERROR] urls[44] = file:/home/username/.m2/repository/org/jbpm/jbpm-flow/6.5.0.Final/jbpm-flow-6.5.0.Final.jar
[ERROR] urls[45] = file:/home/username/.m2/repository/joda-time/joda-time/1.6.2/joda-time-1.6.2.jar
[ERROR] urls[46] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-dtable/6.5.0.Final/drools-workbench-models-guided-dtable-6.5.0.Final.jar
[ERROR] urls[47] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-datamodel-api/6.5.0.Final/drools-workbench-models-datamodel-api-6.5.0.Final.jar
[ERROR] urls[48] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-commons/6.5.0.Final/drools-workbench-models-commons-6.5.0.Final.jar
[ERROR] urls[49] = file:/home/username/.m2/repository/org/apache/commons/commons-lang3/3.1/commons-lang3-3.1.jar
[ERROR] urls[50] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-template/6.5.0.Final/drools-workbench-models-guided-template-6.5.0.Final.jar
[ERROR] urls[51] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-scorecard/6.5.0.Final/drools-workbench-models-guided-scorecard-6.5.0.Final.jar
[ERROR] urls[52] = file:/home/username/.m2/repository/org/slf4j/slf4j-simple/1.7.2/slf4j-simple-1.7.2.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
[ERROR] 
[ERROR] -----------------------------------------------------: java.util.Unkown
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :salve_drools


----

If the type decleration does not use the symbol ie:


{code:java}
package dialogue;

import java.util.Unkown

declare DefaultReply
	symbol:String
end

{code}


the error message becomes a lot better:

[ERROR] Unable to build KieBaseModel:rules
Error importing : 'java.util.Unkown'
[ function parseUtteranceparseUtterance (line:-5): Only a type can be imported. java.util.Unkown resolves to a package
 ]
Rule Compilation error : [Rule name='Parse raw user utterence into parsed utterance (something we understand)']
        dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (2:300) : Only a type can be imported. java.util.Unkown resolves to a package
        dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (2:1068) : The import dialogue.ParseUtterance cannot be resolved
        dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (8:1848) : The method parseUtterance(PatternDatabase, UnparsedUserUtterance, String) is undefined for the type Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339

Rule Compilation error : [Rule name='Pick out the first symbol and insert it']
        dialogue/Rule_Pick_out_the_first_symbol_and_insert_it851572034.java (2:300) : Only a type can be imported. java.util.Unkown resolves to a package
_        [... other rules that fail (not sure if I can show them) .. ]_

Error importing : 'dialogue.ParseUtterance.parseUtterance'

[ERROR] Message [id=1, kieBase=rules, level=ERROR, path=model.drl, line=1, column=0
   text=Error importing : 'java.util.Unkown']
[ERROR] Message [id=2, kieBase=rules, level=ERROR, path=rules.drl, line=-5, column=0
   text=[ function parseUtteranceparseUtterance (line:-5): Only a type can be imported. java.util.Unkown resolves to a package
 ]]
[ERROR] Message [id=3, kieBase=rules, level=ERROR, path=rules.drl, line=32, column=0
   text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
The import dialogue.ParseUtterance cannot be resolved
The method parseUtterance(PatternDatabase, UnparsedUserUtterance, String) is undefined for the type Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339]
[ERROR] Message [id=4, kieBase=rules, level=ERROR, path=rules.drl, line=81, column=0
   text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
The import dialogue.ParseUtterance cannot be resolved]
[ERROR] Message [id=5, kieBase=rules, level=ERROR, path=rules.drl, line=7, column=0
   text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
The import dialogue.ParseUtterance cannot be resolved
The constructor DefaultReply(Symbol) is undefined]
[ERROR] Message [id=6, kieBase=rules, level=ERROR, path=rules.drl, line=90, column=0
   text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
The import dialogue.ParseUtterance cannot be resolved]
[ERROR] Message [id=7, kieBase=rules, level=ERROR, path=rules.drl, line=72, column=0
   text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
The import dialogue.ParseUtterance cannot be resolved
The method randomLiteral(Random) is undefined for the type String]
[ERROR] Message [id=8, kieBase=rules, level=ERROR, path=rules.drl, line=-1, column=0
   text=Error importing : 'dialogue.ParseUtterance.parseUtterance']

----

What I'm missing from the first case is the file name where the linking fails, and the line numbers where Unkown occurs. 
It should also be much more obvious about what symbol can't be found.

Dumping each jar that is used is not very helpful since most people will use maven. It should dump instead all the maven dependencies.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Thu Feb 23 08:32:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-978) MechanismInformationCallback
 blocks certificate based authn (Undertow with Elytron)
In-Reply-To: <JIRA.12678524.1487856658000@Atlassian.JIRA>
References: <JIRA.12678524.1487856658000@Atlassian.JIRA>
	<JIRA.12678524.1487856658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678524.1487856658000.70742.1487856720434@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek moved JBEAP-9074 to ELY-978:
-----------------------------------------

              Project: WildFly Elytron  (was: JBoss Enterprise Application Platform)
                  Key: ELY-978  (was: JBEAP-9074)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: HTTP
                           (was: Security)
    Affects Version/s: 1.1.0.Beta26
                           (was: 7.1.0.DR12)


> 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
>
> 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  Thu Feb 23 08:34:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 08:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-978) MechanismInformationCallback
 blocks certificate based authn (Undertow with Elytron)
In-Reply-To: <JIRA.12678524.1487856658000@Atlassian.JIRA>
References: <JIRA.12678524.1487856658000@Atlassian.JIRA>
	<JIRA.12678524.1487856658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678524.1487856658000.70762.1487856840583@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek updated ELY-978:
-----------------------------
    Attachment: standalone.xml


> 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  Thu Feb 23 08:34:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 08:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-978) MechanismInformationCallback
 blocks certificate based authn (Undertow with Elytron)
In-Reply-To: <JIRA.12678524.1487856658000@Atlassian.JIRA>
References: <JIRA.12678524.1487856658000@Atlassian.JIRA>
	<JIRA.12678524.1487856658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678524.1487856658000.70772.1487856840885@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek updated ELY-978:
-----------------------------
    Attachment: deployment.war


> 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  Thu Feb 23 08:36:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-978) MechanismInformationCallback
 blocks certificate based authn (Undertow with Elytron)
In-Reply-To: <JIRA.12678524.1487856658000@Atlassian.JIRA>
References: <JIRA.12678524.1487856658000@Atlassian.JIRA>
	<JIRA.12678524.1487856658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678524.1487856658000.70794.1487856960048@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368146#comment-13368146 ] 

Ondrej Kotek commented on ELY-978:
----------------------------------

Revealed after fixing ELY-905.

> 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  Thu Feb 23 09:38:01 2017
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Thu, 23 Feb 2017 09:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8131) Aliases in credential stores
 should be case insensitive
In-Reply-To: <JIRA.12677059.1487187855000@Atlassian.JIRA>
References: <JIRA.12677059.1487187855000@Atlassian.JIRA>
	<JIRA.12677059.1487187855000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677059.1487187855000.71485.1487860681671@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek reassigned WFLY-8131:
----------------------------------

    Assignee: Peter Skopek  (was: Darran Lofthouse)


> 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 09:48:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Thu, 23 Feb 2017 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7934) Upgrade JGroups to
	3.6.13.Final
In-Reply-To: <JIRA.12672445.1485162601000@Atlassian.JIRA>
References: <JIRA.12672445.1485162601000@Atlassian.JIRA>
	<JIRA.12672445.1485162601000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672445.1485162601000.71603.1487861280580@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-7934:
---------------------------------
    Description: https://issues.jboss.org/projects/JGRP/versions/12333213


> Upgrade JGroups to 3.6.13.Final
> -------------------------------
>
>                 Key: WFLY-7934
>                 URL: https://issues.jboss.org/browse/WFLY-7934
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Michal Vinkler
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>
> https://issues.jboss.org/projects/JGRP/versions/12333213



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 09:49:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2320) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.71614.1487861340592@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368231#comment-13368231 ] 

Brian Stansberry commented on WFCORE-2320:
------------------------------------------

The "[Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []" logging is a separate issue, although probably with the same general cause -- internal callers not having credentials needed to function with all permissions. 

> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2320
>                 URL: https://issues.jboss.org/browse/WFCORE-2320
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:02:00 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:02: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: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117328@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71838.1487862120889@Atlassian.JIRA>

Scott Van Wart created WFLY-8217:
------------------------------------

             Summary: 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


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:

{{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
	at test.service.TestService.sendMessage(TestService.java:23)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:03:00 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:03: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: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71855.1487862180978@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Attachment: leak.zip


> 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
>
>
> 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:
> {{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
> 10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
> 10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> 	at test.service.TestService.sendMessage(TestService.java:23)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:03:01 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if
 a JMS message is sent from an MDB
In-Reply-To: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71862.1487862181134@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Attachment: leak.zip


> 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
>
>
> 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:
> {{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
> 10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
> 10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> 	at test.service.TestService.sendMessage(TestService.java:23)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:03:01 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if
 a JMS message is sent from an MDB
In-Reply-To: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71869.1487862181393@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Attachment: log.txt


> 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
>
>
> 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:
> {{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
> 10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
> 10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> 	at test.service.TestService.sendMessage(TestService.java:23)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:03:01 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if
 a JMS message is sent from an MDB
In-Reply-To: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71876.1487862181543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Attachment: log.txt


> 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
>
>
> 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:
> {{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
> 10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
> 10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
> 	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
> 	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
> 	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
> 	at test.service.TestService.sendMessage(TestService.java:23)}}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:07:01 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if
 a JMS message is sent from an MDB
In-Reply-To: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71950.1487862421636@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Description: 
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)

  was:
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:

{{10:45:10,692 WARN  [org.jboss.weld.Interceptor] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) WELD-001703: Unable to determine the @Intercepted Bean<?> for [UnbackedAnnotatedField] @Inject @Intercepted private com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.interceptedBean
10:45:10,698 INFO  [test.mdb.TestTopicListener] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) Message In: Hi
10:45:10,704 INFO  [org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-0 (ActiveMQ-client-global-threads-1352698443)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession at 7e39c71f: java.lang.Throwable: STACKTRACE
	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:308)
	at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:777)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
	at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:734)
	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.checkSession(ActiveMQJMSContext.java:142)
	at org.apache.activemq.artemis.jms.client.ActiveMQJMSContext.createTextMessage(ActiveMQJMSContext.java:330)
	at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
	at test.service.TestService.sendMessage(TestService.java:23)}}



> 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
>
>
> 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)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:08:01 2017
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Thu, 23 Feb 2017 10:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8217) ActiveMQ leaks connections if
 a JMS message is sent from an MDB
In-Reply-To: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.71963.1487862481014@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Van Wart updated WFLY-8217:
---------------------------------
    Description: 
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.

  was:
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)



> 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
>
>
> 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  Thu Feb 23 10:31:02 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 10:31:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8218) Add smoke tests for
 certificated based authentication backed by Elytron
In-Reply-To: <JIRA.12678565.1487863839000@Atlassian.JIRA>
References: <JIRA.12678565.1487863839000@Atlassian.JIRA>
	<JIRA.12678565.1487863839304@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678565.1487863839000.72256.1487863862532@Atlassian.JIRA>

Ondrej Kotek created WFLY-8218:
----------------------------------

             Summary: Add smoke tests for certificated based authentication backed by Elytron
                 Key: WFLY-8218
                 URL: https://issues.jboss.org/browse/WFLY-8218
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
    Affects Versions: 11.0.0.Alpha1
            Reporter: Ondrej Kotek
            Assignee: Ondrej Kotek






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:32:00 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 10:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8219) Add smoke tests for
 certificated based authentication backed by Elytron
In-Reply-To: <JIRA.12678567.1487863882000@Atlassian.JIRA>
References: <JIRA.12678567.1487863882000@Atlassian.JIRA>
	<JIRA.12678567.1487863882253@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678567.1487863882000.72265.1487863920810@Atlassian.JIRA>

Ondrej Kotek created WFLY-8219:
----------------------------------

             Summary: Add smoke tests for certificated based authentication backed by Elytron
                 Key: WFLY-8219
                 URL: https://issues.jboss.org/browse/WFLY-8219
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
    Affects Versions: 11.0.0.Alpha1
            Reporter: Ondrej Kotek
            Assignee: Ondrej Kotek






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 10:33:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 23 Feb 2017 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.72309.1487863980853@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368291#comment-13368291 ] 

Bela Ban commented on JGRP-2159:
--------------------------------

[~dan.berindei] Can you reproduce this? I want to create a unit test before looking into a fix.

> 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 Feb 23 10:33:01 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Thu, 23 Feb 2017 10:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8218) Add smoke tests for
 certificate based authentication backed by Elytron
In-Reply-To: <JIRA.12678565.1487863839000@Atlassian.JIRA>
References: <JIRA.12678565.1487863839000@Atlassian.JIRA>
	<JIRA.12678565.1487863839000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678565.1487863839000.72323.1487863981401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek updated WFLY-8218:
-------------------------------
    Summary: Add smoke tests for certificate based authentication backed by Elytron  (was: Add smoke tests for certificated based authentication backed by Elytron)


> Add smoke tests for certificate based authentication backed by Elytron
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8218
>                 URL: https://issues.jboss.org/browse/WFLY-8218
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Kotek
>            Assignee: Ondrej Kotek
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 11:02:00 2017
From: issues at jboss.org (Yusheng Wang (JIRA))
Date: Thu, 23 Feb 2017 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8220) Web Manager Console doesn't
 display module options defined in standalone.xml
In-Reply-To: <JIRA.12678573.1487865696000@Atlassian.JIRA>
References: <JIRA.12678573.1487865696000@Atlassian.JIRA>
	<JIRA.12678573.1487865696913@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678573.1487865696000.72648.1487865720548@Atlassian.JIRA>

Yusheng Wang created WFLY-8220:
----------------------------------

             Summary: Web Manager Console doesn't display module options defined in standalone.xml
                 Key: WFLY-8220
                 URL: https://issues.jboss.org/browse/WFLY-8220
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 10.1.0.Final
            Reporter: Yusheng Wang
            Assignee: Jason Greene
         Attachments: wildfly-bug.png

After fresh installation of Wildfly we got pre-defined security domains such as "jaspitest", "jboss-web-policy" or "other" etc. I can see them also in standalone.xml

{code:xml}
<security-domain name="other" cache-type="default">
	<authentication>
		<login-module code="Remoting" flag="optional">
			<module-option name="password-stacking" value="useFirstPass"/>
		</login-module>
		<login-module code="RealmDirect" flag="required">
			<module-option name="password-stacking" value="useFirstPass"/>
		</login-module>
	</authentication>
</security-domain>
{code}
As you can see, the security domain with name "other" has two login modules defined in authentication, each of them has one module-option defined in it.

But we can not see any definition of module options in web console! (See screenshot in attatchment)

Also in user defined security domains we can not save module options correctly over web console.





--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 11:03:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Feb 2017 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3797) Need post-timeout for WildFly
	/ Undertow
In-Reply-To: <JIRA.12550744.1409537687000@Atlassian.JIRA>
References: <JIRA.12550744.1409537687000@Atlassian.JIRA>
	<JIRA.12550744.1409537687000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12550744.1409537687000.72659.1487865780427@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368324#comment-13368324 ] 

RH Bugzilla Integration commented on WFLY-3797:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1016936|https://bugzilla.redhat.com/show_bug.cgi?id=1016936] from NEW to CLOSED

> Need post-timeout for WildFly / Undertow
> ----------------------------------------
>
>                 Key: WFLY-3797
>                 URL: https://issues.jboss.org/browse/WFLY-3797
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>            Reporter: Lyle Wang
>            Assignee: Stuart Douglas
>             Fix For: 8.2.0.Final, 9.0.0.Beta1
>
>
> Is that possible to provide post timeout to prevent DoS ? JBoss AS 7 or WildFly has no such feature/option, but weblogic provides this:
> http://docs.oracle.com/cd/E17904_01/web.1111/e13701/web_server.htm#i1059782
> Currently only "max-post-size" is supported:
> https://docs.jboss.org/author/display/WFLY8/Undertow+%28web%29+subsystem+configuration



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 11:15:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Thu, 23 Feb 2017 11:15:00 -0500 (EST)
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: <JIRA.12673917.1485869843000@Atlassian.JIRA>
References: <JIRA.12673917.1485869843000@Atlassian.JIRA>
	<JIRA.12673917.1485869843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673917.1485869843000.72711.1487866500128@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368336#comment-13368336 ] 

Filip Brychta commented on HAWKULARQE-9:
----------------------------------------

Link to documentation - 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  Thu Feb 23 11:45:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 11:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8220) Web Manager Console doesn't
 display module options defined in standalone.xml
In-Reply-To: <JIRA.12678573.1487865697000@Atlassian.JIRA>
References: <JIRA.12678573.1487865697000@Atlassian.JIRA>
	<JIRA.12678573.1487865697000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678573.1487865697000.72912.1487868300421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-8220:
--------------------------------------

    Component/s: Web Console
       Assignee: Harald Pehl  (was: Jason Greene)


> Web Manager Console doesn't display module options defined in standalone.xml
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-8220
>                 URL: https://issues.jboss.org/browse/WFLY-8220
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>    Affects Versions: 10.1.0.Final
>            Reporter: Yusheng Wang
>            Assignee: Harald Pehl
>         Attachments: wildfly-bug.png
>
>
> After fresh installation of Wildfly we got pre-defined security domains such as "jaspitest", "jboss-web-policy" or "other" etc. I can see them also in standalone.xml
> {code:xml}
> <security-domain name="other" cache-type="default">
> 	<authentication>
> 		<login-module code="Remoting" flag="optional">
> 			<module-option name="password-stacking" value="useFirstPass"/>
> 		</login-module>
> 		<login-module code="RealmDirect" flag="required">
> 			<module-option name="password-stacking" value="useFirstPass"/>
> 		</login-module>
> 	</authentication>
> </security-domain>
> {code}
> As you can see, the security domain with name "other" has two login modules defined in authentication, each of them has one module-option defined in it.
> But we can not see any definition of module options in web console! (See screenshot in attatchment)
> Also in user defined security domains we can not save module options correctly over web console.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 11:57:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 11:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.73005.1487869020370@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368368#comment-13368368 ] 

Brian Stansberry commented on WFLY-8148:
----------------------------------------

Never mind the previous comment; it still fails intermittently, although the WFLY-8149 fix does prevent the failure resulting in 200 other tests failing.

> 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  Thu Feb 23 11:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.73009.1487869080405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8148:
-----------------------------------
    Comment: was deleted

(was: Never mind the previous comment; it still fails intermittently, although the WFLY-8149 fix does prevent the failure resulting in 200 other tests failing.)


> 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  Thu Feb 23 11:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8148) Intermittent failure in
 InterDeploymentDependenciesEarTestCase
In-Reply-To: <JIRA.12677402.1487281015000@Atlassian.JIRA>
References: <JIRA.12677402.1487281015000@Atlassian.JIRA>
	<JIRA.12677402.1487281015000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677402.1487281015000.73007.1487869080313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8148:
-----------------------------------
    Comment: was deleted

(was: Before anyone spends time on this, I recommend checking if this test stills fails after my WFLY-8149 fix. I don't have a good reason to think it won't, but TBH I don't understand why the changes I made to the original contributor PR for that issue had the effect it did.)


> 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  Thu Feb 23 11:59:00 2017
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Thu, 23 Feb 2017 11:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8221) Upgrade RESTEasy to
	3.0.21.Final
In-Reply-To: <JIRA.12678594.1487869131000@Atlassian.JIRA>
References: <JIRA.12678594.1487869131000@Atlassian.JIRA>
	<JIRA.12678594.1487869131989@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678594.1487869131000.73022.1487869140123@Atlassian.JIRA>

Alessio Soldano created WFLY-8221:
-------------------------------------

             Summary: Upgrade RESTEasy to 3.0.21.Final
                 Key: WFLY-8221
                 URL: https://issues.jboss.org/browse/WFLY-8221
             Project: WildFly
          Issue Type: Component Upgrade
          Components: REST
            Reporter: Alessio Soldano
            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  Thu Feb 23 12:09:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 23 Feb 2017 12:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8222) Regression against 7.0.GA,
 Kerberos over CLI
In-Reply-To: <JIRA.12678600.1487869734000@Atlassian.JIRA>
References: <JIRA.12678600.1487869734000@Atlassian.JIRA>
	<JIRA.12678600.1487869734804@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678600.1487869734000.73234.1487869740315@Atlassian.JIRA>

Martin Choma created WFLY-8222:
----------------------------------

             Summary: Regression against 7.0.GA, Kerberos over CLI
                 Key: WFLY-8222
                 URL: https://issues.jboss.org/browse/WFLY-8222
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


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.<init>(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.<init>(GSSCredentialImpl.java:62)
	at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:154)
	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(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 <CCacheInputStream>  client principal is hnelson7259cb36-69b2-4e28-afb5-f668120a8dea at JBOSS.ORG
>>>DEBUG <CCacheInputStream> server principal is krbtgt/JBOSS.ORG at JBOSS.ORG
>>>DEBUG <CCacheInputStream> key type: 17
>>>DEBUG <CCacheInputStream> auth time: Thu Feb 23 17:32:11 CET 2017
>>>DEBUG <CCacheInputStream> start time: Thu Feb 23 17:32:11 CET 2017
>>>DEBUG <CCacheInputStream> end time: Fri Feb 24 01:32:11 CET 2017
>>>DEBUG <CCacheInputStream> 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  Thu Feb 23 12:34:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Thu, 23 Feb 2017 12:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8223) recovery-credential-reference
 in xa-data-source and resource-adapter doesn't work
In-Reply-To: <JIRA.12678604.1487871234000@Atlassian.JIRA>
References: <JIRA.12678604.1487871234000@Atlassian.JIRA>
	<JIRA.12678604.1487871234943@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678604.1487871234000.73397.1487871240056@Atlassian.JIRA>

Martin Simka created WFLY-8223:
----------------------------------

             Summary: recovery-credential-reference in xa-data-source and resource-adapter doesn't work
                 Key: WFLY-8223
                 URL: https://issues.jboss.org/browse/WFLY-8223
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Martin Simka
            Assignee: Martin Simka


resolved password from {{recovery-credential-reference}} from xa datasource or resource adapter isn't propagated further to ironjacamar



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 12:39:00 2017
From: issues at jboss.org (Martin Simka (JIRA))
Date: Thu, 23 Feb 2017 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8224) recovery-credential-reference
 in xa-data-source and resource-adapter doesn't work
In-Reply-To: <JIRA.12678607.1487871500000@Atlassian.JIRA>
References: <JIRA.12678607.1487871500000@Atlassian.JIRA>
	<JIRA.12678607.1487871500034@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678607.1487871500000.73445.1487871540608@Atlassian.JIRA>

Martin Simka created WFLY-8224:
----------------------------------

             Summary: recovery-credential-reference in xa-data-source and resource-adapter doesn't work
                 Key: WFLY-8224
                 URL: https://issues.jboss.org/browse/WFLY-8224
             Project: WildFly
          Issue Type: Bug
          Components: JCA
            Reporter: Martin Simka
            Assignee: Martin Simka


resolved password from {{recovery-credential-reference}} from xa datasource or resource adapter isn't propagated further to ironjacamar



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 13:41:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 13:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-979) Release WildFly Elytron
	1.1.0.Beta27
In-Reply-To: <JIRA.12678618.1487875215000@Atlassian.JIRA>
References: <JIRA.12678618.1487875215000@Atlassian.JIRA>
	<JIRA.12678618.1487875215382@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678618.1487875215000.73792.1487875260232@Atlassian.JIRA>

Darran Lofthouse created ELY-979:
------------------------------------

             Summary: Release WildFly Elytron 1.1.0.Beta27
                 Key: ELY-979
                 URL: https://issues.jboss.org/browse/ELY-979
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.0.Beta27






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 14:04:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 14:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-980) Form Authentication is missing
 port in redirect.
In-Reply-To: <JIRA.12678623.1487876622000@Atlassian.JIRA>
References: <JIRA.12678623.1487876622000@Atlassian.JIRA>
	<JIRA.12678623.1487876622142@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678623.1487876622000.73886.1487876640144@Atlassian.JIRA>

Darran Lofthouse created ELY-980:
------------------------------------

             Summary: Form Authentication is missing port in redirect.
                 Key: ELY-980
                 URL: https://issues.jboss.org/browse/ELY-980
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 1.1.0.Beta27






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 14:30:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 14:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-980) Add port to FORM auth redirects
 and ensure all redirects use a URL
In-Reply-To: <JIRA.12678623.1487876622000@Atlassian.JIRA>
References: <JIRA.12678623.1487876622000@Atlassian.JIRA>
	<JIRA.12678623.1487876622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678623.1487876622000.73954.1487878200291@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-980:
---------------------------------
    Summary: Add port to FORM auth redirects and ensure all redirects use a URL  (was: Form Authentication is missing port in redirect.)


> Add port to FORM auth redirects and ensure all redirects use a URL
> ------------------------------------------------------------------
>
>                 Key: ELY-980
>                 URL: https://issues.jboss.org/browse/ELY-980
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 14:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 14:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-980) Add port to FORM auth redirects
 and ensure all redirects use a URL
In-Reply-To: <JIRA.12678623.1487876622000@Atlassian.JIRA>
References: <JIRA.12678623.1487876622000@Atlassian.JIRA>
	<JIRA.12678623.1487876622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678623.1487876622000.74023.1487879160830@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-980.
----------------------------------
    Resolution: Done


> Add port to FORM auth redirects and ensure all redirects use a URL
> ------------------------------------------------------------------
>
>                 Key: ELY-980
>                 URL: https://issues.jboss.org/browse/ELY-980
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 1.1.0.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:09:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7462) Do not log common CLI
 failures for Elytron to server log
In-Reply-To: <JIRA.12659191.1478178429000@Atlassian.JIRA>
References: <JIRA.12659191.1478178429000@Atlassian.JIRA>
	<JIRA.12659191.1478178429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659191.1478178429000.74086.1487880540396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368487#comment-13368487 ] 

Brian Stansberry commented on WFLY-7462:
----------------------------------------

The issues driving this (see discussion in JBEAP-6859) are now fixed in WildFly Core, so this can be resolved once core 3.0.0.Beta5 is integrated into full sometime in the next week. I plan to resolve this but am just commenting here in case I forget.

> 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: Darran Lofthouse
>            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  Thu Feb 23 15:17:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2322) Upgrade WildFly Elytron to
	1.1.0.Beta27
In-Reply-To: <JIRA.12678633.1487881011000@Atlassian.JIRA>
References: <JIRA.12678633.1487881011000@Atlassian.JIRA>
	<JIRA.12678633.1487881011722@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678633.1487881011000.74110.1487881020336@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2322:
----------------------------------------

             Summary: Upgrade WildFly Elytron to 1.1.0.Beta27
                 Key: WFCORE-2322
                 URL: https://issues.jboss.org/browse/WFCORE-2322
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta5






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:19:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2323) Upgrade
 wildfly-elytron-tool to 1.0.0.Alpha2
In-Reply-To: <JIRA.12678634.1487881083000@Atlassian.JIRA>
References: <JIRA.12678634.1487881083000@Atlassian.JIRA>
	<JIRA.12678634.1487881083868@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678634.1487881083000.74126.1487881140446@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2323:
----------------------------------------

             Summary: Upgrade wildfly-elytron-tool to 1.0.0.Alpha2
                 Key: WFCORE-2323
                 URL: https://issues.jboss.org/browse/WFCORE-2323
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Scripts, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta5






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:20:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2324) Upgrade Elytron Web to
	1.0.0.Beta12
In-Reply-To: <JIRA.12678635.1487881143000@Atlassian.JIRA>
References: <JIRA.12678635.1487881143000@Atlassian.JIRA>
	<JIRA.12678635.1487881143648@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678635.1487881143000.74140.1487881200671@Atlassian.JIRA>

Darran Lofthouse created WFCORE-2324:
----------------------------------------

             Summary: Upgrade Elytron Web to 1.0.0.Beta12
                 Key: WFCORE-2324
                 URL: https://issues.jboss.org/browse/WFCORE-2324
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 3.0.0.Beta5






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:21:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8225) Upgrade Elytron Subsystem to
	1.0.0.Beta10
In-Reply-To: <JIRA.12678636.1487881258000@Atlassian.JIRA>
References: <JIRA.12678636.1487881258000@Atlassian.JIRA>
	<JIRA.12678636.1487881258576@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678636.1487881258000.74163.1487881260333@Atlassian.JIRA>

Darran Lofthouse created WFLY-8225:
--------------------------------------

             Summary: Upgrade Elytron Subsystem to 1.0.0.Beta10
                 Key: WFLY-8225
                 URL: https://issues.jboss.org/browse/WFLY-8225
             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 Feb 23 15:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2318) Wildfly OpenSSL 1.0.0.Beta6
In-Reply-To: <JIRA.12678414.1487820356000@Atlassian.JIRA>
References: <JIRA.12678414.1487820356000@Atlassian.JIRA>
	<JIRA.12678414.1487820356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678414.1487820356000.74204.1487881560214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2318:
----------------------------------------

    Fix Version/s: 3.0.0.Beta5
         Assignee: Stuart Douglas
       Resolution: Done


> Wildfly OpenSSL 1.0.0.Beta6
> ---------------------------
>
>                 Key: WFCORE-2318
>                 URL: https://issues.jboss.org/browse/WFCORE-2318
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 3.0.0.Beta5
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:40:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2093) A 'start' operation only is
 available for a domain server resource when it is started
In-Reply-To: <JIRA.12666137.1481142564000@Atlassian.JIRA>
References: <JIRA.12666137.1481142564000@Atlassian.JIRA>
	<JIRA.12666137.1481142564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666137.1481142564000.74261.1487882400109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2093:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1


> A 'start' operation only is available for a domain server resource when it is started
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2093
>                 URL: https://issues.jboss.org/browse/WFCORE-2093
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 4.0.0.Beta1
>
>
> The server lifecycle ops are registered with the domain server resource by a call to ServerConfigResourceDefintion.registerServerLifecycleOperations. DomainModelControllerService registers that when the server registers with the HC.
> This is odd in the case of 'start' as it means that op is only registered when the server is started.
> Perhaps it should be registered with StoppedServerResource, although I haven't dug into what happens with that resource when the server is registered. If it is simply ignored that would be great.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-979) Release WildFly Elytron
	1.1.0.Beta27
In-Reply-To: <JIRA.12678618.1487875215000@Atlassian.JIRA>
References: <JIRA.12678618.1487875215000@Atlassian.JIRA>
	<JIRA.12678618.1487875215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678618.1487875215000.74269.1487882521048@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-979.
----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.1.0.Beta27
> ------------------------------------
>
>                 Key: ELY-979
>                 URL: https://issues.jboss.org/browse/ELY-979
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.0.Beta27
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -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: <JIRA.12676714.1487086966000@Atlassian.JIRA>
References: <JIRA.12676714.1487086966000@Atlassian.JIRA>
	<JIRA.12676714.1487086966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676714.1487086966000.74277.1487882521366@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> Presently events could be dropped.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-951) Event handling queues
In-Reply-To: <JIRA.12676713.1487086905000@Atlassian.JIRA>
References: <JIRA.12676713.1487086905000@Atlassian.JIRA>
	<JIRA.12676713.1487086905000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676713.1487086905000.74280.1487882521462@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-950) Add local audit log rotation
In-Reply-To: <JIRA.12676712.1487086827000@Atlassian.JIRA>
References: <JIRA.12676712.1487086827000@Atlassian.JIRA>
	<JIRA.12676712.1487086827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676712.1487086827000.74283.1487882521626@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-949) Add a mechanism to assign
 priorities to audit events
In-Reply-To: <JIRA.12676711.1487086785000@Atlassian.JIRA>
References: <JIRA.12676711.1487086785000@Atlassian.JIRA>
	<JIRA.12676711.1487086785000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676711.1487086785000.74286.1487882521696@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-948) Add additional audit events
In-Reply-To: <JIRA.12676710.1487086731000@Atlassian.JIRA>
References: <JIRA.12676710.1487086731000@Atlassian.JIRA>
	<JIRA.12676710.1487086731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676710.1487086731000.74289.1487882521940@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-942) Review all method names within
	HTTP API
In-Reply-To: <JIRA.12676078.1486812681000@Atlassian.JIRA>
References: <JIRA.12676078.1486812681000@Atlassian.JIRA>
	<JIRA.12676078.1486812681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676078.1486812681000.74292.1487882522013@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-939) We need to be able to support
 standard KeyManager instances
In-Reply-To: <JIRA.12675881.1486695345000@Atlassian.JIRA>
References: <JIRA.12675881.1486695345000@Atlassian.JIRA>
	<JIRA.12675881.1486695345000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675881.1486695345000.74295.1487882522232@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-937) SSLContext in authentication
 client has no trust configuration
In-Reply-To: <JIRA.12675878.1486694187000@Atlassian.JIRA>
References: <JIRA.12675878.1486694187000@Atlassian.JIRA>
	<JIRA.12675878.1486694187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675878.1486694187000.74301.1487882522471@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-936) Complete equivalent of
 CLIENT_CERT authentication for SASL
In-Reply-To: <JIRA.12675877.1486693276000@Atlassian.JIRA>
References: <JIRA.12675877.1486693276000@Atlassian.JIRA>
	<JIRA.12675877.1486693276000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675877.1486693276000.74304.1487882522609@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-930) Support appending a
 CallbackHandler to the CredentialSources
In-Reply-To: <JIRA.12675379.1486498787000@Atlassian.JIRA>
References: <JIRA.12675379.1486498787000@Atlassian.JIRA>
	<JIRA.12675379.1486498787000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675379.1486498787000.74307.1487882522711@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-929) AuthenticationConfiguration
 uniqueness enhancements
In-Reply-To: <JIRA.12675329.1486478892000@Atlassian.JIRA>
References: <JIRA.12675329.1486478892000@Atlassian.JIRA>
	<JIRA.12675329.1486478892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675329.1486478892000.74310.1487882522903@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-926) PKCS#12 support in
 CredentialStore with JDK-8005408
In-Reply-To: <JIRA.12675139.1486406693000@Atlassian.JIRA>
References: <JIRA.12675139.1486406693000@Atlassian.JIRA>
	<JIRA.12675139.1486406693000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675139.1486406693000.74317.1487882523349@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:02 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-938) KeyStore in authentication
 client should not mandate an input source
In-Reply-To: <JIRA.12675879.1486694444000@Atlassian.JIRA>
References: <JIRA.12675879.1486694444000@Atlassian.JIRA>
	<JIRA.12675879.1486694444000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675879.1486694444000.74298.1487882522339@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.74314.1487882523126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-928:
---------------------------------
    Fix Version/s: 1.1.0.Beta28
                       (was: 1.1.0.Beta27)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta28
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-889) Add a filtering RoleMapper
	implementation.
In-Reply-To: <JIRA.12672412.1485006946000@Atlassian.JIRA>
References: <JIRA.12672412.1485006946000@Atlassian.JIRA>
	<JIRA.12672412.1485006946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672412.1485006946000.74320.1487882523526@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:03 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-887) AuthenticationContext IPv6
	Address Handling
In-Reply-To: <JIRA.12671668.1484677904000@Atlassian.JIRA>
References: <JIRA.12671668.1484677904000@Atlassian.JIRA>
	<JIRA.12671668.1484677904000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671668.1484677904000.74323.1487882523805@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-873) AuthenticationClient testing
 without jboss-modules
In-Reply-To: <JIRA.12671058.1484315857000@Atlassian.JIRA>
References: <JIRA.12671058.1484315857000@Atlassian.JIRA>
	<JIRA.12671058.1484315857000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671058.1484315857000.74326.1487882524150@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-861) Role assignment not possible
 for "anonymous" identity
In-Reply-To: <JIRA.12669386.1483548944000@Atlassian.JIRA>
References: <JIRA.12669386.1483548944000@Atlassian.JIRA>
	<JIRA.12669386.1483548944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669386.1483548944000.74330.1487882524424@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-853) OAuth2CredentialSource must
 handle BearerTokenCredential only
In-Reply-To: <JIRA.12668492.1482267272000@Atlassian.JIRA>
References: <JIRA.12668492.1482267272000@Atlassian.JIRA>
	<JIRA.12668492.1482267272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668492.1482267272000.74336.1487882524725@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-849) Rename setMechanismProperties
 to setSaslMechanismProperties
In-Reply-To: <JIRA.12668118.1481996051000@Atlassian.JIRA>
References: <JIRA.12668118.1481996051000@Atlassian.JIRA>
	<JIRA.12668118.1481996051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668118.1481996051000.74339.1487882524913@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:04 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-854) OAuth2SaslServer is missing
 authorization and mechanism information
In-Reply-To: <JIRA.12668493.1482267321000@Atlassian.JIRA>
References: <JIRA.12668493.1482267321000@Atlassian.JIRA>
	<JIRA.12668493.1482267321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668493.1482267321000.74333.1487882524603@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-838) Ability to obtain
 SecurityIdentity without requiring LoginPermission
In-Reply-To: <JIRA.12667874.1481820802000@Atlassian.JIRA>
References: <JIRA.12667874.1481820802000@Atlassian.JIRA>
	<JIRA.12667874.1481820802000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667874.1481820802000.74344.1487882525443@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-822) Move MechanismConfiguration
 from SecurityFactory<Credential> to CredentialSource
In-Reply-To: <JIRA.12666044.1481124509000@Atlassian.JIRA>
References: <JIRA.12666044.1481124509000@Atlassian.JIRA>
	<JIRA.12666044.1481124509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666044.1481124509000.74348.1487882525683@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> Move MechanismConfiguration from SecurityFactory<Credential> 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.Beta28
>
>
> 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 Feb 23 15:42:05 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-810) Unify CredentialStore around
 CredentialSource style storage capability
In-Reply-To: <JIRA.12665175.1480726629000@Atlassian.JIRA>
References: <JIRA.12665175.1480726629000@Atlassian.JIRA>
	<JIRA.12665175.1480726629000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665175.1480726629000.74351.1487882525855@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-774) KeystorePasswordStore needs to
 be optionally passed a Supplier<Provider[]>
In-Reply-To: <JIRA.12662594.1479569524000@Atlassian.JIRA>
References: <JIRA.12662594.1479569524000@Atlassian.JIRA>
	<JIRA.12662594.1479569524000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662594.1479569524000.74355.1487882526003@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> KeystorePasswordStore needs to be optionally passed a Supplier<Provider[]>
> --------------------------------------------------------------------------
>
>                 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.Beta28
>
>
> 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 Feb 23 15:42:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-773) Where
 AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg)
 pass in Supplier<Provider[]>
In-Reply-To: <JIRA.12662591.1479569100000@Atlassian.JIRA>
References: <JIRA.12662591.1479569100000@Atlassian.JIRA>
	<JIRA.12662591.1479569100000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662591.1479569100000.74359.1487882526153@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> Where AuthenticationConfiguration has calls to PasswordFactory.getInstance(alg) pass in Supplier<Provider[]>
> ------------------------------------------------------------------------------------------------------------
>
>                 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.Beta28
>
>
> 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 Feb 23 15:42:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-770) Review SASL mechanism handling
 of isComplete()
In-Reply-To: <JIRA.12662468.1479479730000@Atlassian.JIRA>
References: <JIRA.12662468.1479479730000@Atlassian.JIRA>
	<JIRA.12662468.1479479730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662468.1479479730000.74362.1487882526500@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42: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: <JIRA.12662239.1479397650000@Atlassian.JIRA>
References: <JIRA.12662239.1479397650000@Atlassian.JIRA>
	<JIRA.12662239.1479397650000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662239.1479397650000.74367.1487882526673@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:06 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42: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: <JIRA.12662231.1479392512000@Atlassian.JIRA>
References: <JIRA.12662231.1479392512000@Atlassian.JIRA>
	<JIRA.12662231.1479392512000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662231.1479392512000.74370.1487882526847@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-747) Is
 SSLContextAuthenticationConfiguration Still required now sslRules are
 separated.
In-Reply-To: <JIRA.12661087.1478973495000@Atlassian.JIRA>
References: <JIRA.12661087.1478973495000@Atlassian.JIRA>
	<JIRA.12661087.1478973495000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661087.1478973495000.74374.1487882527116@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:07 -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: <JIRA.12660166.1478609420000@Atlassian.JIRA>
References: <JIRA.12660166.1478609420000@Atlassian.JIRA>
	<JIRA.12660166.1478609420000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660166.1478609420000.74377.1487882527277@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-726) Default Mechanism Ordering
	Implementation
In-Reply-To: <JIRA.12659734.1478514768000@Atlassian.JIRA>
References: <JIRA.12659734.1478514768000@Atlassian.JIRA>
	<JIRA.12659734.1478514768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659734.1478514768000.74381.1487882527476@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-722) Move callback handler
 interactions to a common base class for HTTP mechanisms, .
In-Reply-To: <JIRA.12659529.1478270680000@Atlassian.JIRA>
References: <JIRA.12659529.1478270680000@Atlassian.JIRA>
	<JIRA.12659529.1478270680000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659529.1478270680000.74384.1487882527744@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-662) Eliminate CredentialStore
 interaction from within SASL mechanisms.
In-Reply-To: <JIRA.12654913.1476446086000@Atlassian.JIRA>
References: <JIRA.12654913.1476446086000@Atlassian.JIRA>
	<JIRA.12654913.1476446086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654913.1476446086000.74391.1487882528233@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:07 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-681) Hide private packages from
 generated javadoc.
In-Reply-To: <JIRA.12656512.1477392203000@Atlassian.JIRA>
References: <JIRA.12656512.1477392203000@Atlassian.JIRA>
	<JIRA.12656512.1477392203000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12656512.1477392203000.74387.1487882527916@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-639) SecurityIdentity and
 PeerIdentity should have more runAs* variants
In-Reply-To: <JIRA.12651566.1474559731000@Atlassian.JIRA>
References: <JIRA.12651566.1474559731000@Atlassian.JIRA>
	<JIRA.12651566.1474559731000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651566.1474559731000.74397.1487882528623@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-659) Make all mechanism
	implementations final
In-Reply-To: <JIRA.12654448.1476279388000@Atlassian.JIRA>
References: <JIRA.12654448.1476279388000@Atlassian.JIRA>
	<JIRA.12654448.1476279388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654448.1476279388000.74394.1487882528455@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-621) Client Cert authentication
 trigger SSLSession renegotiation?
In-Reply-To: <JIRA.12644753.1472127460000@Atlassian.JIRA>
References: <JIRA.12644753.1472127460000@Atlassian.JIRA>
	<JIRA.12644753.1472127460000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12644753.1472127460000.74401.1487882528756@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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
>             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  Thu Feb 23 15:42:08 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-617) Review 'null' handling for
 MechanismConfiguration and MechanismRealmConfiguration
In-Reply-To: <JIRA.12641565.1470136074000@Atlassian.JIRA>
References: <JIRA.12641565.1470136074000@Atlassian.JIRA>
	<JIRA.12641565.1470136074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641565.1470136074000.74404.1487882528893@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-613) Some nested classes should be
 considered to be static nested in Elytron
In-Reply-To: <JIRA.12641227.1469789814000@Atlassian.JIRA>
References: <JIRA.12641227.1469789814000@Atlassian.JIRA>
	<JIRA.12641227.1469789814000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641227.1469789814000.74409.1487882529015@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-609) Unguarded read in
	ElytronPolicyConfiguration
In-Reply-To: <JIRA.12641222.1469789012000@Atlassian.JIRA>
References: <JIRA.12641222.1469789012000@Atlassian.JIRA>
	<JIRA.12641222.1469789012000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12641222.1469789012000.74413.1487882529104@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-601) Adjust all
 AuthenticationConfiguration 'use' methods to more closely match the schema
In-Reply-To: <JIRA.12640663.1469539027000@Atlassian.JIRA>
References: <JIRA.12640663.1469539027000@Atlassian.JIRA>
	<JIRA.12640663.1469539027000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640663.1469539027000.74416.1487882529170@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -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: <JIRA.12640625.1469529058000@Atlassian.JIRA>
References: <JIRA.12640625.1469529058000@Atlassian.JIRA>
	<JIRA.12640625.1469529058000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640625.1469529058000.74419.1487882529249@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-595) Ability to provide
 CallbackHandler and SSLContext when AuthenticationConfiguration dynamically
 loaded.
In-Reply-To: <JIRA.12640311.1469199395000@Atlassian.JIRA>
References: <JIRA.12640311.1469199395000@Atlassian.JIRA>
	<JIRA.12640311.1469199395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640311.1469199395000.74422.1487882529319@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-490) Add JavaDoc for the
 'org.wildfly.security.ssl' package and sub packages.
In-Reply-To: <JIRA.12613309.1459854206000@Atlassian.JIRA>
References: <JIRA.12613309.1459854206000@Atlassian.JIRA>
	<JIRA.12613309.1459854206000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613309.1459854206000.74433.1487882529606@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-486) Add JavaDoc for the
 'org.wildfly.security.credential' package and sub packages.
In-Reply-To: <JIRA.12613298.1459853853000@Atlassian.JIRA>
References: <JIRA.12613298.1459853853000@Atlassian.JIRA>
	<JIRA.12613298.1459853853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613298.1459853853000.74438.1487882529772@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-489) Add JavaDoc for the
 'org.wildfly.security.mechanism' package and sub packages.
In-Reply-To: <JIRA.12613308.1459854107000@Atlassian.JIRA>
References: <JIRA.12613308.1459854107000@Atlassian.JIRA>
	<JIRA.12613308.1459854107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613308.1459854107000.74435.1487882529655@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-477)
 XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
In-Reply-To: <JIRA.12613085.1459771072000@Atlassian.JIRA>
References: <JIRA.12613085.1459771072000@Atlassian.JIRA>
	<JIRA.12613085.1459771072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613085.1459771072000.74444.1487882529893@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-449) Add CredentialStore support to
 Elytron client configuration
In-Reply-To: <JIRA.12610491.1458044783000@Atlassian.JIRA>
References: <JIRA.12610491.1458044783000@Atlassian.JIRA>
	<JIRA.12610491.1458044783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610491.1458044783000.74452.1487882530078@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-559) Token-based authentication
 should forward authentication
In-Reply-To: <JIRA.12629124.1464822065000@Atlassian.JIRA>
References: <JIRA.12629124.1464822065000@Atlassian.JIRA>
	<JIRA.12629124.1464822065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12629124.1464822065000.74425.1487882529417@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-524) RealmIdentity data caching
 support in the LDAP realm
In-Reply-To: <JIRA.12618201.1462379575000@Atlassian.JIRA>
References: <JIRA.12618201.1462379575000@Atlassian.JIRA>
	<JIRA.12618201.1462379575000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618201.1462379575000.74429.1487882529515@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-455) OAuth2 Credential Store
In-Reply-To: <JIRA.12610625.1458113565000@Atlassian.JIRA>
References: <JIRA.12610625.1458113565000@Atlassian.JIRA>
	<JIRA.12610625.1458113565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610625.1458113565000.74449.1487882530011@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:42:09 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:09 -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: <JIRA.12613296.1459853809000@Atlassian.JIRA>
References: <JIRA.12613296.1459853809000@Atlassian.JIRA>
	<JIRA.12613296.1459853809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613296.1459853809000.74441.1487882529839@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB
	subsystems
In-Reply-To: <JIRA.12569743.1429897656000@Atlassian.JIRA>
References: <JIRA.12569743.1429897656000@Atlassian.JIRA>
	<JIRA.12569743.1429897656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569743.1429897656000.74462.1487882530407@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:42:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-298) load-from/uri keystore
	xsd/parser mismatch
In-Reply-To: <JIRA.12586656.1443615679000@Atlassian.JIRA>
References: <JIRA.12586656.1443615679000@Atlassian.JIRA>
	<JIRA.12586656.1443615679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586656.1443615679000.74456.1487882530273@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> The xsd has
> {code}
>   <xsd:complexType name="key-store-type">
>         <xsd:sequence minOccurs="1" maxOccurs="1">
>             <!-- Access source type -->
>             <xsd:choice minOccurs="1" maxOccurs="1">
>                 <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
>                 <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {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 Feb 23 15:42:10 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 15:42:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-211) Client-side trust store
	configuration
In-Reply-To: <JIRA.12574700.1434031461000@Atlassian.JIRA>
References: <JIRA.12574700.1434031461000@Atlassian.JIRA>
	<JIRA.12574700.1434031461000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574700.1434031461000.74459.1487882530334@Atlassian.JIRA>


     [ 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.Beta28
                       (was: 1.1.0.Beta27)


> 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.Beta28
>
>
> 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 Feb 23 15:55:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6409) Update default domain
 configuration to use remote+http
In-Reply-To: <JIRA.12611162.1458392141000@Atlassian.JIRA>
References: <JIRA.12611162.1458392141000@Atlassian.JIRA>
	<JIRA.12611162.1458392141000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611162.1458392141000.74551.1487883300208@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-6409:
-----------------------------------
    Priority: Major  (was: Minor)


> 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: 11.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  Thu Feb 23 15:56:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8226) Update default domain
 configuration to use remote+http
In-Reply-To: <JIRA.12678642.1487883313000@Atlassian.JIRA>
References: <JIRA.12678642.1487883313000@Atlassian.JIRA>
	<JIRA.12678642.1487883313111@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678642.1487883313000.74554.1487883360756@Atlassian.JIRA>

Brian Stansberry created WFLY-8226:
--------------------------------------

             Summary: Update default domain configuration to use remote+http
                 Key: WFLY-8226
                 URL: https://issues.jboss.org/browse/WFLY-8226
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: ehsavoie Hugonnet
            Assignee: ehsavoie Hugonnet
             Fix For: 11.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  Thu Feb 23 16:00:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 16:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-456) Add a content-stream
 attribute to the root deployment=* resources
In-Reply-To: <JIRA.12559179.1418228755000@Atlassian.JIRA>
References: <JIRA.12559179.1418228755000@Atlassian.JIRA>
	<JIRA.12559179.1418228755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559179.1418228755000.74612.1487883600450@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-456:
------------------------------------
    Fix Version/s: 4.0.0.Beta1


> Add a content-stream attribute to the root deployment=* resources
> -----------------------------------------------------------------
>
>                 Key: WFCORE-456
>                 URL: https://issues.jboss.org/browse/WFCORE-456
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: ehsavoie Hugonnet
>             Fix For: 4.0.0.Beta1
>
>
> Add a new attribute to the deployment resource that allows the user to get a stream with the deployment content attached to the response, a la what we do with the subsystem=logging/log-file=* resource's "stream" attribute.
> The attribute must be configured as runtime-only and read-only.
> The read handler that handles the attribute should only attach a stream if the following conditions are met, otherwise the value for the attribute should remain as 'undefined'.
> 1) The resource's "content" attribute has only a single element in the list. (This is always the case today; adding a check for this is just future proofing)
> 2) The first element in the "content" attribute list has a defined value in its "hash" field. (This confirms the content is stored in the content repo. We won't support serving unmanaged content as we have insufficient control over it.)
> 3) The first element in the "content" attribute list has a 'true' as value of its "archive" field.  (Current this will always be the case; this is future proofing for when we add support for exploded content in the content repo. Trying to assemble a stream from exploded content is currently out of scope for this feature.)



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 15:44:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 15:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6565) add and remove operation of
 jaxrs subsystem under deployment are useles and should not be available
In-Reply-To: <JIRA.12617168.1461772489000@Atlassian.JIRA>
References: <JIRA.12617168.1461772489000@Atlassian.JIRA>
	<JIRA.12617168.1461772489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12617168.1461772489000.74487.1487882640452@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reopened WFLY-6565:
------------------------------------


Reopening to align with the downstream issue, which QE reopened.

Let's just drop these handlers. If there's any logic that is counting on executing them it is almost certainly broken.

> add and remove operation of jaxrs subsystem under deployment are useles and should not be available
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6565
>                 URL: https://issues.jboss.org/browse/WFLY-6565
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 11.0.0.Alpha1
>
>
> *Description of problem:*
> "add" and "remove" operation of jaxrs subsystem under deployment are useles and should not be available.
> This operations were added by WFLY-3045.
> *How reproducible:*
> Always
> *Steps to Reproduce (remove):*
> # ./standalone.sh 
> # deploy /home/mkopecky/playground/resteasy/single-application/target/jaxrs-eap.war
> # /deployment=jaxrs-eap.war/subsystem=jaxrs:remove
> #  :reload
> # # jaxrs subsystem is not removed
> *Steps to Reproduce (add):*
> # deploy /home/mkopecky/playground/resteasy/empty-deployment/target/empty-eap.war
> # /deployment=empty-eap.war/subsystem=jaxrs:add()
> # :reload
> # # jaxrs subsystem is not added



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 16:07:00 2017
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 23 Feb 2017 16:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1063) Improvement: Provide CLI
	preferences
In-Reply-To: <JIRA.12457644.1327596146000@Atlassian.JIRA>
References: <JIRA.12457644.1327596146000@Atlassian.JIRA>
	<JIRA.12457644.1327596146000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457644.1327596146000.74664.1487884020446@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368520#comment-13368520 ] 

RH Bugzilla Integration commented on WFLY-1063:
-----------------------------------------------

Brad Maxwell <bmaxwell at redhat.com> changed the Status of [bug 1139111|https://bugzilla.redhat.com/show_bug.cgi?id=1139111] from NEW to CLOSED

> Improvement: Provide CLI preferences
> ------------------------------------
>
>                 Key: WFLY-1063
>                 URL: https://issues.jboss.org/browse/WFLY-1063
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Heiko Braun
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Final
>
>
> preferences on for default settings:
> [4:37pm] hbraun: CLI preferences would be cool
> [4:37pm] hbraun: i am tired of writing recursive=true all the time
> alias for address tokens:
> [4:38pm] hbraun: plus an address book: prod-db = /subsystem=jadada/database=jadada/
> [4:38pm] hbraun: so you could call prod-db:read-resource



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 17:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 23 Feb 2017 17:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8130) Upgrade WildFly Transaction
 Client to 1.0.0.Beta14
In-Reply-To: <JIRA.12677042.1487180248000@Atlassian.JIRA>
References: <JIRA.12677042.1487180248000@Atlassian.JIRA>
	<JIRA.12677042.1487180248000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677042.1487180248000.75576.1487890620409@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-8130.
------------------------------------
    Resolution: Done


> Upgrade WildFly Transaction Client to 1.0.0.Beta14
> --------------------------------------------------
>
>                 Key: WFLY-8130
>                 URL: https://issues.jboss.org/browse/WFLY-8130
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            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 Feb 23 17:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 23 Feb 2017 17:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2237) Upgrade Undertow to 1.4.9
In-Reply-To: <JIRA.12673471.1485536154000@Atlassian.JIRA>
References: <JIRA.12673471.1485536154000@Atlassian.JIRA>
	<JIRA.12673471.1485536154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673471.1485536154000.75579.1487890680157@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed WFCORE-2237.
------------------------------------
    Resolution: Out of Date


We're at 1.4.11.

> Upgrade Undertow to 1.4.9
> -------------------------
>
>                 Key: WFCORE-2237
>                 URL: https://issues.jboss.org/browse/WFCORE-2237
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>    Affects Versions: 3.0.0.Alpha22
>            Reporter: Paul Ferraro
>
> Containing fix for https://issues.jboss.org/browse/UNDERTOW-976



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 19:30:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Thu, 23 Feb 2017 19:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8227) Ensure principalVsRolesMap
 always gets processed when using Elytron regardless of whether or not JACC
 is enabled
In-Reply-To: <JIRA.12678666.1487896151000@Atlassian.JIRA>
References: <JIRA.12678666.1487896151000@Atlassian.JIRA>
	<JIRA.12678666.1487896151615@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678666.1487896151000.75911.1487896200298@Atlassian.JIRA>

Farah Juma created WFLY-8227:
--------------------------------

             Summary: Ensure principalVsRolesMap always gets processed when using Elytron regardless of whether or not JACC is enabled
                 Key: WFLY-8227
                 URL: https://issues.jboss.org/browse/WFLY-8227
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Farah Juma
            Assignee: Farah Juma


We're currently not processing the principalVsRolesMap when using an Elytron security domain with JACC disabled.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Thu Feb 23 22:58:00 2017
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Thu, 23 Feb 2017 22:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-11) Create a simple web page
In-Reply-To: <JIRA.12678374.1487788739000@Atlassian.JIRA>
References: <JIRA.12678374.1487788739000@Atlassian.JIRA>
	<JIRA.12678374.1487788739000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678374.1487788739000.76114.1487908680166@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-11.
-----------------------------
    Resolution: Done


Online at https://agroal.github.io

> Create a simple web page
> ------------------------
>
>                 Key: AG-11
>                 URL: https://issues.jboss.org/browse/AG-11
>             Project: Agroal
>          Issue Type: Task
>          Components: web
>    Affects Versions: 0.1
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>             Fix For: 0.2
>
>
> Using GitHub pages



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 02:01:00 2017
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Fri, 24 Feb 2017 02:01: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: <JIRA.12678551.1487862117000@Atlassian.JIRA>
References: <JIRA.12678551.1487862117000@Atlassian.JIRA>
	<JIRA.12678551.1487862117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678551.1487862117000.76300.1487919660272@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368674#comment-13368674 ] 

Miroslav Novak commented on WFLY-8217:
--------------------------------------

[~silvaran] Hi, could you try it with latest WF11 nightly build [1]. There is a chance that this was fixed already. 

[1] https://ci.wildfly.org/guestAuth/repository/download/WF_Nightly/latest.lastFinished/wildfly-11.0.0.Alpha1-SNAPSHOT.zip

> 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
>
>
> 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  Fri Feb 24 02:42:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 02:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution
 fails to work with Elytron - NoClassDefFoundError
In-Reply-To: <JIRA.12678678.1487922083000@Atlassian.JIRA>
References: <JIRA.12678678.1487922083000@Atlassian.JIRA>
	<JIRA.12678678.1487922083816@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678678.1487922083000.76353.1487922121690@Atlassian.JIRA>

Josef Cacek created WFLY-8228:
---------------------------------

             Summary: 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: Darran Lofthouse
            Priority: Critical


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  Fri Feb 24 02:42:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 02:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution
 fails to work with Elytron - NoClassDefFoundError
In-Reply-To: <JIRA.12678678.1487922084000@Atlassian.JIRA>
References: <JIRA.12678678.1487922084000@Atlassian.JIRA>
	<JIRA.12678678.1487922084000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678678.1487922084000.76364.1487922121996@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-8228:
------------------------------
    Priority: Blocker  (was: Critical)


> 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: Darran Lofthouse
>            Priority: Blocker
>
> 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  Fri Feb 24 03:10:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 24 Feb 2017 03:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579055000@Atlassian.JIRA>
References: <JIRA.12677693.1487579055000@Atlassian.JIRA>
	<JIRA.12677693.1487579055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579055000.76465.1487923800793@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-1445.
---------------------------------
    Fix Version/s: 7.0.0.CR1
       Resolution: Done


Fixed by https://github.com/droolsjbpm/drools/commit/ff8d793b248c42029d0571742c9d0c7c284e3590

> Mask should reflect properties accessed in other nodes join constraints
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1445
>                 URL: https://issues.jboss.org/browse/DROOLS-1445
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.CR1
>
>
> The following test exhibit a failing and a working test:
> {code:java}
>     @Test()
>     public void testAbis_NotWorking() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "    $p2 : Person( age > $p1.age ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         ksession.addEventListener(new DebugAgendaEventListener());
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
>     
>     @Test()
>     public void testAbis_Working() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
>                 "    $p2 : Person( age > $a1 ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 03:47:03 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Fri, 24 Feb 2017 03:47:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2325) User in any role can read
 sensitive configuration with RBAC enable in domain
In-Reply-To: <JIRA.12678694.1487925981000@Atlassian.JIRA>
References: <JIRA.12678694.1487925981000@Atlassian.JIRA>
	<JIRA.12678694.1487925981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678694.1487925981000.76725.1487926023288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel reassigned WFCORE-2325:
---------------------------------

    Assignee:     (was: Brian Stansberry)


> User in any role can read sensitive configuration with RBAC enable in domain
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-2325
>                 URL: https://issues.jboss.org/browse/WFCORE-2325
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> User in any role can read sensitive configuration (e.g. authorization settings) in RBAC in domain. If user checks for assigned roles, the SuperUser is always given as a result ({{"mapped-roles" => ["SuperUser"]}}) - see result of step 12, no matter what roles should be mapped according to configuration.
> User can then read any part of the configuration, e.g. following command {{/core-service=management/access=authorization/role-mapping=SuperUser:read-resource(recursive)}} results in output similar to:
> {code}
> {
>     "outcome" => "success",
>     "result" => {
>         "include-all" => false,
>         "exclude" => undefined,
>         "include" => {
>             "user-$local" => {
>                 "name" => "$local",
>                 "realm" => undefined,
>                 "type" => "USER"
>             },
>             "user-admin" => {
>                 "name" => "admin",
>                 "realm" => undefined,
>                 "type" => "USER"
>             }
>         }
>     },
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> However, user cannot add himself/herself to SuperUser role, if {{/core-service=management/access=authorization/role-mapping=SuperUser/include=user-user:add(name=user,type=USER)}} command is entered, the following output is given:
> {code}
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found"}}},
>         "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found",
>             "rolled-back" => true,
>             "response-headers" => {"process-state" => "reload-required"}
>         }}}}},
>         "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found",
>             "rolled-back" => true,
>             "response-headers" => {"process-state" => "reload-required"}
>         }}}}}
>     },
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> Therefore, user in Monitor role has not the same rights as user in SuperUser role since (s)he is missing (at least) rights to write. However, (s)he can see any part of the configuration.
> This is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 03:47:02 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Fri, 24 Feb 2017 03:47:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2325) User in any role can read
 sensitive configuration with RBAC enable in domain
In-Reply-To: <JIRA.12678694.1487925981000@Atlassian.JIRA>
References: <JIRA.12678694.1487925981000@Atlassian.JIRA>
	<JIRA.12678694.1487925981226@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678694.1487925981000.76710.1487926022449@Atlassian.JIRA>

Jan Tymel created WFCORE-2325:
---------------------------------

             Summary: User in any role can read sensitive configuration with RBAC enable in domain
                 Key: WFCORE-2325
                 URL: https://issues.jboss.org/browse/WFCORE-2325
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Security
            Reporter: Jan Tymel
            Assignee: Brian Stansberry
            Priority: Blocker


User in any role can read sensitive configuration (e.g. authorization settings) in RBAC in domain. If user checks for assigned roles, the SuperUser is always given as a result ({{"mapped-roles" => ["SuperUser"]}}) - see result of step 12, no matter what roles should be mapped according to configuration.
User can then read any part of the configuration, e.g. following command {{/core-service=management/access=authorization/role-mapping=SuperUser:read-resource(recursive)}} results in output similar to:
{code}
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-$local" => {
                "name" => "$local",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-admin" => {
                "name" => "admin",
                "realm" => undefined,
                "type" => "USER"
            }
        }
    },
    "response-headers" => {"process-state" => "reload-required"}
}
{code}

However, user cannot add himself/herself to SuperUser role, if {{/core-service=management/access=authorization/role-mapping=SuperUser/include=user-user:add(name=user,type=USER)}} command is entered, the following output is given:
{code}
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
        "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => "WFLYCTL0216: Management resource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"SuperUser\"),
    (\"include\" => \"user-user\")
]' not found"}}},
        "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => "WFLYCTL0216: Management resource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"SuperUser\"),
    (\"include\" => \"user-user\")
]' not found"}}}
    }}},
    "rolled-back" => true,
    "server-groups" => {
        "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => {"response" => {
            "outcome" => "failed",
            "result" => undefined,
            "failure-description" => "WFLYCTL0216: Management resource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"SuperUser\"),
    (\"include\" => \"user-user\")
]' not found",
            "rolled-back" => true,
            "response-headers" => {"process-state" => "reload-required"}
        }}}}},
        "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => {"response" => {
            "outcome" => "failed",
            "result" => undefined,
            "failure-description" => "WFLYCTL0216: Management resource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"SuperUser\"),
    (\"include\" => \"user-user\")
]' not found",
            "rolled-back" => true,
            "response-headers" => {"process-state" => "reload-required"}
        }}}}}
    },
    "response-headers" => {"process-state" => "reload-required"}
}
{code}

Therefore, user in Monitor role has not the same rights as user in SuperUser role since (s)he is missing (at least) rights to write. However, (s)he can see any part of the configuration.

This is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 04:09:02 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 04:09:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8229) When Elytron is used redirect
 from j_security_check uses HTTP code 303
In-Reply-To: <JIRA.12678701.1487927335000@Atlassian.JIRA>
References: <JIRA.12678701.1487927335000@Atlassian.JIRA>
	<JIRA.12678701.1487927335152@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678701.1487927335000.76840.1487927342108@Atlassian.JIRA>

Josef Cacek created WFLY-8229:
---------------------------------

             Summary: When Elytron is used redirect from j_security_check uses HTTP code 303
                 Key: WFLY-8229
                 URL: https://issues.jboss.org/browse/WFLY-8229
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow), Security
            Reporter: Josef Cacek
            Assignee: Stuart Douglas
            Priority: Blocker


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 Feb 24 04:10:01 2017
From: issues at jboss.org (Jan Tymel (JIRA))
Date: Fri, 24 Feb 2017 04:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2325) User in any role can read
 sensitive configuration with RBAC enable in domain
In-Reply-To: <JIRA.12678694.1487925981000@Atlassian.JIRA>
References: <JIRA.12678694.1487925981000@Atlassian.JIRA>
	<JIRA.12678694.1487925981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678694.1487925981000.76873.1487927401716@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Tymel updated WFCORE-2325:
------------------------------
    Security Sensitive Issue: This issue is security relevant


> User in any role can read sensitive configuration with RBAC enable in domain
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-2325
>                 URL: https://issues.jboss.org/browse/WFCORE-2325
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Priority: Blocker
>
> User in any role can read sensitive configuration (e.g. authorization settings) in RBAC in domain. If user checks for assigned roles, the SuperUser is always given as a result ({{"mapped-roles" => ["SuperUser"]}}) - see result of step 12, no matter what roles should be mapped according to configuration.
> User can then read any part of the configuration, e.g. following command {{/core-service=management/access=authorization/role-mapping=SuperUser:read-resource(recursive)}} results in output similar to:
> {code}
> {
>     "outcome" => "success",
>     "result" => {
>         "include-all" => false,
>         "exclude" => undefined,
>         "include" => {
>             "user-$local" => {
>                 "name" => "$local",
>                 "realm" => undefined,
>                 "type" => "USER"
>             },
>             "user-admin" => {
>                 "name" => "admin",
>                 "realm" => undefined,
>                 "type" => "USER"
>             }
>         }
>     },
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> However, user cannot add himself/herself to SuperUser role, if {{/core-service=management/access=authorization/role-mapping=SuperUser/include=user-user:add(name=user,type=USER)}} command is entered, the following output is given:
> {code}
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {
>         "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found"}}},
>         "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found"}}}
>     }}},
>     "rolled-back" => true,
>     "server-groups" => {
>         "main-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-one" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found",
>             "rolled-back" => true,
>             "response-headers" => {"process-state" => "reload-required"}
>         }}}}},
>         "other-server-group" => {"host" => {"dhcp-4-212.brq.redhat.com" => {"server-two" => {"response" => {
>             "outcome" => "failed",
>             "result" => undefined,
>             "failure-description" => "WFLYCTL0216: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"SuperUser\"),
>     (\"include\" => \"user-user\")
> ]' not found",
>             "rolled-back" => true,
>             "response-headers" => {"process-state" => "reload-required"}
>         }}}}}
>     },
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> Therefore, user in Monitor role has not the same rights as user in SuperUser role since (s)he is missing (at least) rights to write. However, (s)he can see any part of the configuration.
> This is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 04:56:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 04:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8230) EJB tests are failing in AS
 TS with Elytron profile
In-Reply-To: <JIRA.12678726.1487930104000@Atlassian.JIRA>
References: <JIRA.12678726.1487930104000@Atlassian.JIRA>
	<JIRA.12678726.1487930104385@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678726.1487930104000.77355.1487930160082@Atlassian.JIRA>

Josef Cacek created WFLY-8230:
---------------------------------

             Summary: EJB tests are failing in AS TS with Elytron profile
                 Key: WFLY-8230
                 URL: https://issues.jboss.org/browse/WFLY-8230
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: Josef Cacek


Tests in {{org.jboss.as.test.integration.naming.remote.multiple}} package are failing when using {{"-Delytron"}} argument.

{code}
cd testsuite/integration/basic
mvn clean test -Dtest=org.jboss.as.test.integration.naming.remote.multiple.* -Delytron
...
Tests in error: 
  MultipleClientRemoteJndiTestCase.testLifeCycle:86 ? IO java.util.concurrent.Ex...
  NestedRemoteContextTestCase.testLifeCycle:76 ? IO java.util.concurrent.Executi...

Tests run: 2, Failures: 0, Errors: 2, Skipped: 0
{code}


Related stack trace in the server log:
{code}
10:30:28,402 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /web/CallEjbServlet: java.lang.RuntimeException: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   JBOSS-LOCAL-USER: Server rejected authentication]
        at org.jboss.as.test.integration.naming.remote.multiple.CallEjbServlet.doGet(CallEjbServlet.java:44)
        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.handleRequest(ElytronRunAsHandler.java:60)
        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.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.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:1700)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
        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)
Caused by: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   JBOSS-LOCAL-USER: Server rejected authentication]
        at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:91)
        at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:109)
        at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:99)
        at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:108)
        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:131)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at org.jboss.as.test.integration.naming.remote.multiple.CallEjbServlet.doGet(CallEjbServlet.java:36)
        ... 36 more
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   JBOSS-LOCAL-USER: Server rejected authentication
        at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:110)
        at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:414)
        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:464)
        at org.jboss.remoting3.FutureConnection.getConnection(FutureConnection.java:117)
        at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:77)
        at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:152)
        at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:397)
        at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:340)
        at org.wildfly.naming.client.remote.RemoteNamingProvider.lambda$new$0(RemoteNamingProvider.java:65)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity(RemoteNamingProvider.java:107)
        at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:89)
        ... 45 more
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Fri Feb 24 05:03:00 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Fri, 24 Feb 2017 05:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8231) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12678727.1487930532000@Atlassian.JIRA>
References: <JIRA.12678727.1487930532000@Atlassian.JIRA>
	<JIRA.12678727.1487930532256@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678727.1487930532000.77418.1487930580454@Atlassian.JIRA>

Peter Palaga created WFLY-8231:
----------------------------------

             Summary: ldap role should ignore javax.naming.PartialResultException when referrals=ignore
                 Key: WFLY-8231
                 URL: https://issues.jboss.org/browse/WFLY-8231
             Project: WildFly
          Issue Type: Task
          Components: Security
            Reporter: Peter Palaga
            Assignee: Darran Lofthouse


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
	ref 1: 'AGENTS.AMFAM.NET'
\00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 05:04:00 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Fri, 24 Feb 2017 05:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8231) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12678727.1487930532000@Atlassian.JIRA>
References: <JIRA.12678727.1487930532000@Atlassian.JIRA>
	<JIRA.12678727.1487930532000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678727.1487930532000.77433.1487930640333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga reassigned WFLY-8231:
----------------------------------

    Assignee: Peter Palaga  (was: Darran Lofthouse)


> ldap role should ignore javax.naming.PartialResultException when referrals=ignore
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8231
>                 URL: https://issues.jboss.org/browse/WFLY-8231
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 
> ldap role should ignore javax.naming.PartialResultException when referrals=ignore.
> In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
> {code}
> 15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
> 15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
> 	ref 1: 'AGENTS.AMFAM.NET'
> \00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
> 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
> 	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
> 	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
> 	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> 	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> {code}
> Setting referrals=follows worked around the issue in this case.
> Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 05:37:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Feb 2017 05:37:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8229) When Elytron is used redirect
 from j_security_check uses HTTP code 303
In-Reply-To: <JIRA.12678701.1487927335000@Atlassian.JIRA>
References: <JIRA.12678701.1487927335000@Atlassian.JIRA>
	<JIRA.12678701.1487927335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678701.1487927335000.77751.1487932621093@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-8229:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Stuart Douglas)


> When Elytron is used redirect from j_security_check uses HTTP code 303
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8229
>                 URL: https://issues.jboss.org/browse/WFLY-8229
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> 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 Feb 24 05:37:01 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 24 Feb 2017 05:37:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8229) When Elytron is used redirect
 from j_security_check uses HTTP code 303
In-Reply-To: <JIRA.12678701.1487927335000@Atlassian.JIRA>
References: <JIRA.12678701.1487927335000@Atlassian.JIRA>
	<JIRA.12678701.1487927335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678701.1487927335000.77760.1487932621377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8229:
-----------------------------------
    Fix Version/s: 11.0.0.Alpha1


> When Elytron is used redirect from j_security_check uses HTTP code 303
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8229
>                 URL: https://issues.jboss.org/browse/WFLY-8229
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> 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 Feb 24 06:00:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 24 Feb 2017 06:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1450) Validation rule
 ITEMDEF_NOT_UNIQUE not allowing two structure with same attributes
In-Reply-To: <JIRA.12678740.1487933946000@Atlassian.JIRA>
References: <JIRA.12678740.1487933946000@Atlassian.JIRA>
	<JIRA.12678740.1487933946066@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678740.1487933946000.77921.1487934000155@Atlassian.JIRA>

Matteo Mortari created DROOLS-1450:
--------------------------------------

             Summary: Validation rule ITEMDEF_NOT_UNIQUE not allowing two structure with same attributes
                 Key: DROOLS-1450
                 URL: https://issues.jboss.org/browse/DROOLS-1450
             Project: Drools
          Issue Type: Bug
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 06:59:01 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 24 Feb 2017 06:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2326) Upgrade to jboss-modules
	1.6.0 Beta6
In-Reply-To: <JIRA.12678753.1487937528000@Atlassian.JIRA>
References: <JIRA.12678753.1487937528000@Atlassian.JIRA>
	<JIRA.12678753.1487937528279@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678753.1487937528000.78393.1487937541273@Atlassian.JIRA>

Tomaz Cerar created WFCORE-2326:
-----------------------------------

             Summary: Upgrade to jboss-modules 1.6.0 Beta6
                 Key: WFCORE-2326
                 URL: https://issues.jboss.org/browse/WFCORE-2326
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Modules
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


Update modules to latest version.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:01:02 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 07:01:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8232) SecurityAuditingTestCase
 fails with Elytron profile in AS TS
In-Reply-To: <JIRA.12678756.1487937651000@Atlassian.JIRA>
References: <JIRA.12678756.1487937651000@Atlassian.JIRA>
	<JIRA.12678756.1487937651989@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678756.1487937651000.78459.1487937662152@Atlassian.JIRA>

Josef Cacek created WFLY-8232:
---------------------------------

             Summary: SecurityAuditingTestCase fails with Elytron profile in AS TS
                 Key: WFLY-8232
                 URL: https://issues.jboss.org/browse/WFLY-8232
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite, Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse


The {{SecurityAuditingTestCase}} fails when executed with Elytron profile ({{-Delytron}}) in AS TS.

{code}
cd testsuite/integration/basic
mvn clean test -Dtest=SecurityAuditingTestCase -Delytron
...
Failed tests: 
  SecurityAuditingTestCase.testSingleMethodAnnotationsUser1Template:181->AnnSBTest.testSingleMethodAnnotationsUser1Template:156->AnnSBTest.lambda$testSingleMethodAnnotationsUser1Template$1:169 EJBAccessException not expected

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:04:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 24 Feb 2017 07:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2326) Upgrade to jboss-modules
	1.6.0 Beta5
In-Reply-To: <JIRA.12678753.1487937528000@Atlassian.JIRA>
References: <JIRA.12678753.1487937528000@Atlassian.JIRA>
	<JIRA.12678753.1487937528000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678753.1487937528000.78500.1487937840223@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFCORE-2326:
--------------------------------
    Summary: Upgrade to jboss-modules 1.6.0 Beta5  (was: Upgrade to jboss-modules 1.6.0 Beta6)


> Upgrade to jboss-modules 1.6.0 Beta5
> ------------------------------------
>
>                 Key: WFCORE-2326
>                 URL: https://issues.jboss.org/browse/WFCORE-2326
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Modules
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>
> Update modules to latest version.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.78570.1487938024405@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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
>             Fix For: 3.0.0.Beta6
>
>
> 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 Feb 24 07:07:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07: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: <JIRA.12677290.1487258960000@Atlassian.JIRA>
References: <JIRA.12677290.1487258960000@Atlassian.JIRA>
	<JIRA.12677290.1487258960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677290.1487258960000.78577.1487938024826@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2302:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07: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: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.78581.1487938024942@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2301:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Beta6, 2.2.1.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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 Feb 24 07:07:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.78588.1487938025174@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.78597.1487938025491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.78601.1487938025588@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta6, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Fri Feb 24 07:07:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.78608.1487938025772@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07: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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.78615.1487938025906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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 Feb 24 07:07:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.78625.1487938026217@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:06 -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: <JIRA.12666705.1481282688000@Atlassian.JIRA>
References: <JIRA.12666705.1481282688000@Atlassian.JIRA>
	<JIRA.12666705.1481282688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666705.1481282688000.78632.1487938026432@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron
	1.1.0.Final
In-Reply-To: <JIRA.12666683.1481279343000@Atlassian.JIRA>
References: <JIRA.12666683.1481279343000@Atlassian.JIRA>
	<JIRA.12666683.1481279343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666683.1481279343000.78639.1487938026633@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.78648.1487938026847@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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 Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.78655.1487938027024@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.78663.1487938027227@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>         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 Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.78682.1487938027789@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1964:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta6
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.78674.1487938027603@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta6
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.78671.1487938027464@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -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: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.78686.1487938027874@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>         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<String, String>, 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 Feb 24 07:07:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.78691.1487938027968@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.78704.1487938028335@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07: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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.78698.1487938028124@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.78712.1487938028638@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:08 -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: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.78717.1487938028909@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:09 -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: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.78726.1487938029236@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:09 -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: <JIRA.12626950.1463652179000@Atlassian.JIRA>
References: <JIRA.12626950.1463652179000@Atlassian.JIRA>
	<JIRA.12626950.1463652179000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626950.1463652179000.78730.1487938029330@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>         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 Feb 24 07:07:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1441) Threads resource classes
 should make it easy for users to declare capabilities
In-Reply-To: <JIRA.12610985.1458236449000@Atlassian.JIRA>
References: <JIRA.12610985.1458236449000@Atlassian.JIRA>
	<JIRA.12610985.1458236449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610985.1458236449000.78733.1487938029451@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1441:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> Threads resource classes should make it easy for users to declare capabilities
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-1441
>                 URL: https://issues.jboss.org/browse/WFCORE-1441
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta6
>
>
> The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking.
> But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities.
> Things probably needed:
> 1) Ability to declare the capability that should be registered when a resource is created.
> 2) Ability to declare the capability that model reference attributes in a resource refer to.
> Perhaps others, but those are the ones that come immediately to mind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:09 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.78744.1487938029982@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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: David Lloyd
>            Priority: Critical
>             Fix For: 3.0.0.Beta6
>
>         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 Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.78753.1487938030216@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>         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 Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.78780.1487938030942@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-459:
------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta6
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.78767.1487938030605@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> "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.Beta6
>
>
> 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 Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.78759.1487938030375@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:11 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.78784.1487938031123@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.78763.1487938030461@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.78788.1487938031211@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-266:
------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta6
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:07:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.78797.1487938031522@Atlassian.JIRA>


     [ 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.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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 Feb 24 07:07:10 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.78774.1487938030758@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> 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.Beta6
>
>
> 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.<init>(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 Feb 24 07:07:11 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 07:07:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.78791.1487938031278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-107:
------------------------------
    Fix Version/s: 3.0.0.Beta6
                       (was: 3.0.0.Beta5)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta6
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 07:33:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 07:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8233) Messaging SecurityTestCase
 fails with Elytron profile in AS TS
In-Reply-To: <JIRA.12678764.1487939544000@Atlassian.JIRA>
References: <JIRA.12678764.1487939544000@Atlassian.JIRA>
	<JIRA.12678764.1487939544271@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678764.1487939544000.79175.1487939581789@Atlassian.JIRA>

Josef Cacek created WFLY-8233:
---------------------------------

             Summary: Messaging SecurityTestCase fails with Elytron profile in AS TS
                 Key: WFLY-8233
                 URL: https://issues.jboss.org/browse/WFLY-8233
             Project: WildFly
          Issue Type: Bug
          Components: JMS, Test Suite
            Reporter: Josef Cacek
            Assignee: Jeff Mesnil


The {{SecurityTestCase#testFailedAuthenticationBlankUserPass()}} test fails when executed with Elytron profile ({{-Delytron}}).

{code}
cd testsuite/integration/basic
mvn clean test -Dtest=SecurityTestCase -Delytron
...
Failed tests: 
  SecurityTestCase.testFailedAuthenticationBlankUserPass:84 must not allow to create a session without any authentication

Tests run: 6, Failures: 1, Errors: 0, Skipped: 0
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 08:39:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 08:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8090) Changing Elytron
 default-authentication-context requires server restart
In-Reply-To: <JIRA.12676146.1486966368000@Atlassian.JIRA>
References: <JIRA.12676146.1486966368000@Atlassian.JIRA>
	<JIRA.12676146.1486966368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676146.1486966368000.79759.1487943541232@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-8090.
------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> Changing Elytron default-authentication-context requires server restart
> -----------------------------------------------------------------------
>
>                 Key: WFLY-8090
>                 URL: https://issues.jboss.org/browse/WFLY-8090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>         Attachments: AuthnContextApp.war
>
>
> In case when Elytron subsystem attribute default-authentication-context is changed (through write-attribute or undefine-attribute operation) then operation succeed and server is NOT set to reload-required state. However changed value is not used until server is reload.
> Before fixing, it must be decided whether change of default-authentication-context should require server reload or not. [~dlofthouse] What should be correct behavior?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 08:39:01 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Fri, 24 Feb 2017 08:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8229) When Elytron is used redirect
 from j_security_check uses HTTP code 303
In-Reply-To: <JIRA.12678701.1487927335000@Atlassian.JIRA>
References: <JIRA.12678701.1487927335000@Atlassian.JIRA>
	<JIRA.12678701.1487927335000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678701.1487927335000.79773.1487943541567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-8229.
------------------------------
    Resolution: Done


> When Elytron is used redirect from j_security_check uses HTTP code 303
> ----------------------------------------------------------------------
>
>                 Key: WFLY-8229
>                 URL: https://issues.jboss.org/browse/WFLY-8229
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>            Reporter: Josef Cacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> 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 Feb 24 09:05:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 24 Feb 2017 09:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.79962.1487945101254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-928:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 1.1.0.Beta28
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 09:06:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 24 Feb 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.79975.1487945160557@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-928:
---------------------------------

    Assignee: Darran Lofthouse  (was: Ilia Vassilev)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>              Labels: user_experience
>             Fix For: 1.1.0.Beta28
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 09:08:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 24 Feb 2017 09:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-928) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.79992.1487945280185@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-928:
---------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: ELY-928
>                 URL: https://issues.jboss.org/browse/ELY-928
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>             Fix For: 1.1.0.Beta28
>
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 09:10:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Fri, 24 Feb 2017 09:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8234) RemoteAsyncInvocationTestCase
 fails with Elytron profile in AS TS
In-Reply-To: <JIRA.12678781.1487945353000@Atlassian.JIRA>
References: <JIRA.12678781.1487945353000@Atlassian.JIRA>
	<JIRA.12678781.1487945353518@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678781.1487945353000.80021.1487945401069@Atlassian.JIRA>

Josef Cacek created WFLY-8234:
---------------------------------

             Summary: 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 Feb 24 09:12:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 24 Feb 2017 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8235) Wrong type of Elytron
	match-no-user in XSD
In-Reply-To: <JIRA.12675260.1486469518000@Atlassian.JIRA>
References: <JIRA.12675260.1486469518000@Atlassian.JIRA>
	<JIRA.12675260.1486469518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675260.1486469518000.80059.1487945520524@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved ELY-928 to WFLY-8235:
-----------------------------------------

          Project: WildFly  (was: WildFly Elytron)
              Key: WFLY-8235  (was: ELY-928)
      Component/s: Security
                       (was: Authentication Client)
    Fix Version/s:     (was: 1.1.0.Beta28)


> Wrong type of Elytron match-no-user in XSD
> ------------------------------------------
>
>                 Key: WFLY-8235
>                 URL: https://issues.jboss.org/browse/WFLY-8235
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>              Labels: user_experience
>
> {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 09:42:00 2017
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Fri, 24 Feb 2017 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8228) Servlet server distribution
 fails to work with Elytron - NoClassDefFoundError
In-Reply-To: <JIRA.12678678.1487922084000@Atlassian.JIRA>
References: <JIRA.12678678.1487922084000@Atlassian.JIRA>
	<JIRA.12678678.1487922084000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678678.1487922084000.80369.1487947320591@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFLY-8228:
--------------------------------

    Assignee: Ingo Weiss  (was: Darran Lofthouse)


> 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
>
> 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  Fri Feb 24 09:50:01 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 24 Feb 2017 09:50:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6496) EJB IIOP calls from EAP6 to
 EAP7 and vice versa stopped working in 7.0.0.ER7
In-Reply-To: <JIRA.12613466.1459900110000@Atlassian.JIRA>
References: <JIRA.12613466.1459900110000@Atlassian.JIRA>
	<JIRA.12613466.1459900110000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613466.1459900110000.80439.1487947801277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-6496.
--------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


> EJB IIOP calls from EAP6 to EAP7 and vice versa stopped working in 7.0.0.ER7
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-6496
>                 URL: https://issues.jboss.org/browse/WFLY-6496
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Security
>    Affects Versions: 10.0.0.Final
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 09:51:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 24 Feb 2017 09:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6496) EJB IIOP calls from EAP6 to
 EAP7 and vice versa stopped working in 7.0.0.ER7
In-Reply-To: <JIRA.12613466.1459900110000@Atlassian.JIRA>
References: <JIRA.12613466.1459900110000@Atlassian.JIRA>
	<JIRA.12613466.1459900110000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613466.1459900110000.80476.1487947860569@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369038#comment-13369038 ] 

Tomasz Adamski commented on WFLY-6496:
--------------------------------------

This issue was fixed in EAP 7.0.0.Final and merged to upstream through elytron-incubator.

> EJB IIOP calls from EAP6 to EAP7 and vice versa stopped working in 7.0.0.ER7
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-6496
>                 URL: https://issues.jboss.org/browse/WFLY-6496
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, Security
>    Affects Versions: 10.0.0.Final
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:01:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431457@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80571.1487948460134@Atlassian.JIRA>

Jan Kalina created WFCORE-2327:
----------------------------------

             Summary: embed-server froze during start when RBAC used
                 Key: WFCORE-2327
                 URL: https://issues.jboss.org/browse/WFCORE-2327
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 3.0.0.Alpha17
            Reporter: Jan Kalina


When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.

{code}
bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] embed-server --std-out=echo
15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
15:55:42,302 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.
15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
{code}
In this stage it froze and need to be interrupted by Ctrl+C.
{code}
Interrupted while waiting for embedded server to start
[disconnected /]
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:02:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80575.1487948520213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-2327:
-------------------------------
    Attachment: standalone.xml


> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:03:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Feb 2017 10:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1441) Threads resource classes
 should make it easy for users to declare capabilities
In-Reply-To: <JIRA.12610985.1458236449000@Atlassian.JIRA>
References: <JIRA.12610985.1458236449000@Atlassian.JIRA>
	<JIRA.12610985.1458236449000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610985.1458236449000.80585.1487948580562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1441:
-------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta6)


> Threads resource classes should make it easy for users to declare capabilities
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-1441
>                 URL: https://issues.jboss.org/browse/WFCORE-1441
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> The classes in the threads modules are now meant for shared use by subsystems in setting up consistent management of thread related resources. An important aspect of that management is the declaration of capabilities, particularly for use in capability-driven model integrity checking.
> But the threads module classes do not include any hooks to let the calling code specify the relevant capabilities.
> Things probably needed:
> 1) Ability to declare the capability that should be registered when a resource is created.
> 2) Ability to declare the capability that model reference attributes in a resource refer to.
> Perhaps others, but those are the ones that come immediately to mind.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:08:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80637.1487948881278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369056#comment-13369056 ] 

Jan Kalina commented on WFCORE-2327:
------------------------------------

This blocks WFLY-7949 - adding CLI skript enabling elytron into wildfly testsuite.

> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:09:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80663.1487948940756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-2327:
-------------------------------
    Steps to Reproduce: 
Change "simple" to "rbac" in standalone.xml: (or use attached standalone.xml)
{code:xml}
<access-control provider="rbac">
{code}
Start embed-server in CLI of wildfly-core:
{code}
bin/jboss-cli.sh
embed-server --std-out=echo
{code}

  was:
Change "simple" to "rbac" in standalone.xml: (or use attached standalone.xml)
{code:xml}
<access-control provider="rbac">
{code}
Start embed-server:
{code}
bin/jboss-cli.sh
embed-server --std-out=echo
{code}



> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:09:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80652.1487948940453@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369056#comment-13369056 ] 

Jan Kalina edited comment on WFCORE-2327 at 2/24/17 10:08 AM:
--------------------------------------------------------------

This blocks WFLY-7949 - adding CLI skript enabling elytron into wildfly testsuite. (or at least their enabling)


was (Author: honza889):
This blocks WFLY-7949 - adding CLI skript enabling elytron into wildfly testsuite.

> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:19:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 24 Feb 2017 10:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6875) Add ssl-enabled-protocol
 configuration parameter to IIOP subsystem
In-Reply-To: <JIRA.12640415.1469368197000@Atlassian.JIRA>
References: <JIRA.12640415.1469368197000@Atlassian.JIRA>
	<JIRA.12640415.1469368197000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12640415.1469368197000.80758.1487949540718@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-6875.
--------------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Done


This issue was fixed inside elytron-integration.

> Add ssl-enabled-protocol configuration parameter to IIOP subsystem
> ------------------------------------------------------------------
>
>                 Key: WFLY-6875
>                 URL: https://issues.jboss.org/browse/WFLY-6875
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: IIOP
>    Affects Versions: 10.0.0.Final
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>             Fix For: 11.0.0.Alpha1
>
>
> Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter independently of JVM making it secure no matter what JVM implementation is used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:19:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 10:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.80761.1487949540853@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-2327:
-------------------------------
    Priority: Critical  (was: Major)


> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>            Priority: Critical
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:29:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 24 Feb 2017 10:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7789) Upgrade jboss-ejb-client to
	4.0.0.Beta2
In-Reply-To: <JIRA.12667465.1481654981000@Atlassian.JIRA>
References: <JIRA.12667465.1481654981000@Atlassian.JIRA>
	<JIRA.12667465.1481654981000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667465.1481654981000.80830.1487950140499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-7789.
--------------------------------
    Resolution: Done


> Upgrade jboss-ejb-client to 4.0.0.Beta2
> ---------------------------------------
>
>                 Key: WFLY-7789
>                 URL: https://issues.jboss.org/browse/WFLY-7789
>             Project: WildFly
>          Issue Type: Component Upgrade
>    Affects Versions: 10.1.0.Final
>            Reporter: Tomasz Adamski
>            Assignee: Tomasz Adamski
>             Fix For: 11.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:31:00 2017
From: issues at jboss.org (Tomasz Adamski (JIRA))
Date: Fri, 24 Feb 2017 10:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6326) Comments in IIOP xsd schema
 contain terms 'on' and 'off' but they should be true/false
In-Reply-To: <JIRA.12609188.1457343856000@Atlassian.JIRA>
References: <JIRA.12609188.1457343856000@Atlassian.JIRA>
	<JIRA.12609188.1457343856000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609188.1457343856000.80838.1487950260403@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomasz Adamski closed WFLY-6326.
--------------------------------
    Fix Version/s: 10.1.0.Final
       Resolution: Done


> Comments in IIOP xsd schema contain terms 'on' and 'off' but they should be true/false
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-6326
>                 URL: https://issues.jboss.org/browse/WFLY-6326
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP
>    Affects Versions: 10.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Tomasz Adamski
>            Priority: Minor
>             Fix For: 10.1.0.Final
>
>
> Comments of xsd schema under docs/schema/jboss-as-iiop-openjdk_1_0.xsd contains terms _on_ and _off_ but those values are wrong to be set into management model. For openjdk iiop values _true_ and _false_ are valid.
> Comments should be in sync with variables which are real to be set.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 10:40:00 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Fri, 24 Feb 2017 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.80859.1487950800092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369081#comment-13369081 ] 

Michal Petrov commented on WFCORE-2317:
---------------------------------------

[~brian.stansberry], I think I have a working solution [for ObjectValue|https://github.com/michpetrov/wildfly-core/commit/efb8b24f2acbd7fad0e551cc23261ec0035342f0]. My assumption is that requires/alternatives is only meant for siblings (and as such list and map do not need to be validated), should it work over the entire tree?

> 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
>             Fix For: 3.0.0.Beta6
>
>
> 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 Feb 24 11:09:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 24 Feb 2017 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8236) Upgrade HAL to 2.9.3.Final
In-Reply-To: <JIRA.12678815.1487952514000@Atlassian.JIRA>
References: <JIRA.12678815.1487952514000@Atlassian.JIRA>
	<JIRA.12678815.1487952514000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678815.1487952514000.81008.1487952540853@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Harald Pehl updated WFLY-8236:
------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/9627)


> Upgrade HAL to 2.9.3.Final
> --------------------------
>
>                 Key: WFLY-8236
>                 URL: https://issues.jboss.org/browse/WFLY-8236
>             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  Fri Feb 24 11:09:00 2017
From: issues at jboss.org (Harald Pehl (JIRA))
Date: Fri, 24 Feb 2017 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8236) Upgrade HAL to 2.9.3.Final
In-Reply-To: <JIRA.12678815.1487952513000@Atlassian.JIRA>
References: <JIRA.12678815.1487952513000@Atlassian.JIRA>
	<JIRA.12678815.1487952513661@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678815.1487952513000.81000.1487952540513@Atlassian.JIRA>

Harald Pehl created WFLY-8236:
---------------------------------

             Summary: Upgrade HAL to 2.9.3.Final
                 Key: WFLY-8236
                 URL: https://issues.jboss.org/browse/WFLY-8236
             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  Fri Feb 24 11:38:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Feb 2017 11:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.81298.1487954280554@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369120#comment-13369120 ] 

Brian Stansberry commented on WFCORE-2317:
------------------------------------------

[~michpetrov]

Nice! I haven't had time to look, but it's nice you are attacking this. Since you are working this, please assign it to yourself.

"My assumption is that requires/alternatives is only meant for siblings (and as such list and map do not need to be validated)"

Two answers -- the theoretical and the practical:

Theoretical:

The elements of the list and the values in the map should be validated individually for internal correctness, if those elements/values themselves use ObjectTypeAtributeDefinition. Those checks can be limited to cases where the enclosing list/map uses ObjectListAttributeDefinition or ObjectMapAttributeDefinition. There is no need to validate across list elements or map values.

Practical:

I see no uses of ObjectMapAttributeDefinition in WildFly. I'm glad, as maps of objects are fairly ugly. So dealing with it is not a priority.

There are some uses of ObjectListAttributeDefinition. I don't see any uses of requires/alternatives in those, so dealing with lists is not a priority.

I believe my IDE search would have caught any uses in the elytron subsystem, but it's good to double check, particularly for list. It's uses of list in the elytron subsystem that would provide some motivation to get the list handling in, since that's new API and correctness of security config is more important than most config. Otherwise I'd be fine with ignoring lists at this point.


> 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
>             Fix For: 3.0.0.Beta6
>
>
> 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 Feb 24 11:52:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Feb 2017 11:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2320) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.81369.1487955120465@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2320:
----------------------------------------

    Assignee: Brian Stansberry


> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2320
>                 URL: https://issues.jboss.org/browse/WFCORE-2320
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Assignee: Brian Stansberry
>            Priority: Blocker
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 11:52:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Feb 2017 11:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.81373.1487955120540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2327:
----------------------------------------

    Assignee: Brian Stansberry


> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>            Assignee: Brian Stansberry
>            Priority: Critical
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 12:08:01 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Fri, 24 Feb 2017 12:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.81470.1487956081399@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369143#comment-13369143 ] 

Michal Petrov commented on WFCORE-2317:
---------------------------------------

{quote}
The elements of the list and the values in the map should be validated individually for internal correctness, if those elements/values themselves use ObjectTypeAtributeDefinition.
{quote}
Right, didn't think of that. I'll check how it works.

> 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
>             Fix For: 3.0.0.Beta6
>
>
> 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 Feb 24 12:08:01 2017
From: issues at jboss.org (Michal Petrov (JIRA))
Date: Fri, 24 Feb 2017 12:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.81481.1487956081673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Petrov reassigned WFCORE-2317:
-------------------------------------

    Assignee: Michal Petrov


> 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.Beta6
>
>
> 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 Feb 24 12:53:00 2017
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 24 Feb 2017 12:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8237) Upgrade to xalan
 2.7.1.jbossorg-3 and include fix for cve-2014-0107
In-Reply-To: <JIRA.12678838.1487958729000@Atlassian.JIRA>
References: <JIRA.12678838.1487958729000@Atlassian.JIRA>
	<JIRA.12678838.1487958729000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678838.1487958729000.81641.1487958780563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow moved JBEAP-9127 to WFLY-8237:
-------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-8237  (was: JBEAP-9127)
     Issue Type: Task  (was: Bug)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: XML Frameworks
                     (was: XML Frameworks)


> Upgrade to xalan 2.7.1.jbossorg-3 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  Fri Feb 24 13:07:00 2017
From: issues at jboss.org (Marek Winkler (JIRA))
Date: Fri, 24 Feb 2017 13:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1451) NPE when building KieBase
 with OOPath in a declared window
In-Reply-To: <JIRA.12678839.1487959567000@Atlassian.JIRA>
References: <JIRA.12678839.1487959567000@Atlassian.JIRA>
	<JIRA.12678839.1487959567056@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678839.1487959567000.81658.1487959620154@Atlassian.JIRA>

Marek Winkler created DROOLS-1451:
-------------------------------------

             Summary: NPE when building KieBase with OOPath in a declared window
                 Key: DROOLS-1451
                 URL: https://issues.jboss.org/browse/DROOLS-1451
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.Beta6
         Environment: Reproducible with 7.0.0-SNAPSHOT.
            Reporter: Marek Winkler
            Assignee: Mario Fusco


When using an OOPath expression in a declared window (does not matter if a length or a time window), a NPE is thrown. For instance, a rule such as:

{code}
declare window Pings
  MessageEvent( /msg{ message == 'Ping' } ) over window:length( 2 )
end

rule R when
  $messageEvent: MessageEvent() from window Pings
then
  events.add( $messageEvent );
end
{code}

produces the following exception (see the attachment for the full stacktrace) when building the KieBase:
{code}
java.lang.NullPointerException
	at org.drools.core.reteoo.builder.WindowReferenceBuilder.build(WindowReferenceBuilder.java:40)
	at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:116)
	at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:77)
	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:164)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
...
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:630)
...
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 13:09:00 2017
From: issues at jboss.org (Marek Winkler (JIRA))
Date: Fri, 24 Feb 2017 13:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1451) NPE when building KieBase
 with OOPath in a declared window
In-Reply-To: <JIRA.12678839.1487959567000@Atlassian.JIRA>
References: <JIRA.12678839.1487959567000@Atlassian.JIRA>
	<JIRA.12678839.1487959567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678839.1487959567000.81663.1487959740304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Winkler updated DROOLS-1451:
----------------------------------
    Attachment: oopath-cep-stacktrace.txt


> NPE when building KieBase with OOPath in a declared window
> ----------------------------------------------------------
>
>                 Key: DROOLS-1451
>                 URL: https://issues.jboss.org/browse/DROOLS-1451
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>         Environment: Reproducible with 7.0.0-SNAPSHOT.
>            Reporter: Marek Winkler
>            Assignee: Mario Fusco
>         Attachments: oopath-cep-stacktrace.txt
>
>
> When using an OOPath expression in a declared window (does not matter if a length or a time window), a NPE is thrown. For instance, a rule such as:
> {code}
> declare window Pings
>   MessageEvent( /msg{ message == 'Ping' } ) over window:length( 2 )
> end
> rule R when
>   $messageEvent: MessageEvent() from window Pings
> then
>   events.add( $messageEvent );
> end
> {code}
> produces the following exception (see the attachment for the full stacktrace) when building the KieBase:
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.builder.WindowReferenceBuilder.build(WindowReferenceBuilder.java:40)
> 	at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:116)
> 	at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:77)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:164)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
> 	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> ...
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:630)
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 13:14:00 2017
From: issues at jboss.org (Marek Winkler (JIRA))
Date: Fri, 24 Feb 2017 13:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1451) NPE when building KieBase
 with OOPath in a declared window
In-Reply-To: <JIRA.12678839.1487959567000@Atlassian.JIRA>
References: <JIRA.12678839.1487959567000@Atlassian.JIRA>
	<JIRA.12678839.1487959567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678839.1487959567000.81666.1487960040159@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Winkler updated DROOLS-1451:
----------------------------------
    Steps to Reproduce: 
Please run the tests {{org.drools.testcoverage.functional.oopath.OOPathCepTest}} for declared windows (does not matter if time or length) from PR \[1].

\[1] https://github.com/droolsjbpm/drools/pull/1117


> NPE when building KieBase with OOPath in a declared window
> ----------------------------------------------------------
>
>                 Key: DROOLS-1451
>                 URL: https://issues.jboss.org/browse/DROOLS-1451
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>         Environment: Reproducible with 7.0.0-SNAPSHOT.
>            Reporter: Marek Winkler
>            Assignee: Mario Fusco
>         Attachments: oopath-cep-stacktrace.txt
>
>
> When using an OOPath expression in a declared window (does not matter if a length or a time window), a NPE is thrown. For instance, a rule such as:
> {code}
> declare window Pings
>   MessageEvent( /msg{ message == 'Ping' } ) over window:length( 2 )
> end
> rule R when
>   $messageEvent: MessageEvent() from window Pings
> then
>   events.add( $messageEvent );
> end
> {code}
> produces the following exception (see the attachment for the full stacktrace) when building the KieBase:
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.builder.WindowReferenceBuilder.build(WindowReferenceBuilder.java:40)
> 	at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:116)
> 	at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:77)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:164)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
> 	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> ...
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:630)
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 14:22:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 24 Feb 2017 14:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2328) CLI connect command should
 accept a --bind parameter
In-Reply-To: <JIRA.12678845.1487964069000@Atlassian.JIRA>
References: <JIRA.12678845.1487964069000@Atlassian.JIRA>
	<JIRA.12678845.1487964069853@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678845.1487964069000.81759.1487964120154@Atlassian.JIRA>

Brian Stansberry created WFCORE-2328:
----------------------------------------

             Summary: CLI connect command should accept a --bind parameter
                 Key: WFCORE-2328
                 URL: https://issues.jboss.org/browse/WFCORE-2328
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
            Reporter: Brian Stansberry
            Priority: Minor


When you launch the CLI you can pass a --bind=xxx param which then controls the client side bind address used for connections. But you can't specify this with the connect command itself.

This is minor; I just noticed it while experimenting with the fix for WFCORE-2225 when I wanted to confirm the fix was working by using the CLI.

Also, I noticed that if I did a "connect --bind=192.168.1.10" the CLI accepted the invalide command.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 15:36:01 2017
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Fri, 24 Feb 2017 15:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968504000@Atlassian.JIRA>
References: <JIRA.12678852.1487968504000@Atlassian.JIRA>
	<JIRA.12678852.1487968504801@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968504000.81949.1487968561043@Atlassian.JIRA>

Claudio Miranda created WFLY-8238:
-------------------------------------

             Summary: 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: Jeff Mesnil


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}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 15:40:01 2017
From: issues at jboss.org (Claudio Miranda (JIRA))
Date: Fri, 24 Feb 2017 15:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.82048.1487968801235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claudio Miranda updated WFLY-8238:
----------------------------------
    Description: 
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}

  was:
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}



> 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: Jeff Mesnil
>
> 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 Feb 24 15:45:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 24 Feb 2017 15:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8239) Upgrade jgroups-azure to
	1.1.0.Final
In-Reply-To: <JIRA.12678858.1487969064000@Atlassian.JIRA>
References: <JIRA.12678858.1487969064000@Atlassian.JIRA>
	<JIRA.12678858.1487969064486@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678858.1487969064000.82096.1487969100696@Atlassian.JIRA>

Radoslav Husar created WFLY-8239:
------------------------------------

             Summary: Upgrade jgroups-azure to 1.1.0.Final
                 Key: WFLY-8239
                 URL: https://issues.jboss.org/browse/WFLY-8239
             Project: WildFly
          Issue Type: Task
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


* azure-storage client v5 upgrade
* wrong configuration parameters now correctly fail fast
* project testable with JDK9



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 15:47:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 24 Feb 2017 15:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8240) Upgrade jgroups-azure to
	1.1.0.Final
In-Reply-To: <JIRA.12678860.1487969176000@Atlassian.JIRA>
References: <JIRA.12678860.1487969176000@Atlassian.JIRA>
	<JIRA.12678860.1487969176013@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678860.1487969176000.82108.1487969220698@Atlassian.JIRA>

Radoslav Husar created WFLY-8240:
------------------------------------

             Summary: Upgrade jgroups-azure to 1.1.0.Final
                 Key: WFLY-8240
                 URL: https://issues.jboss.org/browse/WFLY-8240
             Project: WildFly
          Issue Type: Task
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar


* azure-storage client v5 upgrade
* wrong configuration parameters now correctly fail fast
* project testable with JDK9



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 15:47:01 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 24 Feb 2017 15:47:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8239) Upgrade jgroups-azure to
	1.1.0.Final
In-Reply-To: <JIRA.12678858.1487969064000@Atlassian.JIRA>
References: <JIRA.12678858.1487969064000@Atlassian.JIRA>
	<JIRA.12678858.1487969064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678858.1487969064000.82128.1487969221303@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8239:
---------------------------------
    Issue Type: Component Upgrade  (was: Task)


> Upgrade jgroups-azure to 1.1.0.Final
> ------------------------------------
>
>                 Key: WFLY-8239
>                 URL: https://issues.jboss.org/browse/WFLY-8239
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> * azure-storage client v5 upgrade
> * wrong configuration parameters now correctly fail fast
> * project testable with JDK9



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 15:48:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 24 Feb 2017 15:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8239) Upgrade jgroups-azure to
	1.1.0.Final
In-Reply-To: <JIRA.12678858.1487969064000@Atlassian.JIRA>
References: <JIRA.12678858.1487969064000@Atlassian.JIRA>
	<JIRA.12678858.1487969064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678858.1487969064000.82141.1487969280299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-8239:
---------------------------------
    Affects Version/s: 10.1.0.Final


> Upgrade jgroups-azure to 1.1.0.Final
> ------------------------------------
>
>                 Key: WFLY-8239
>                 URL: https://issues.jboss.org/browse/WFLY-8239
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> * azure-storage client v5 upgrade
> * wrong configuration parameters now correctly fail fast
> * project testable with JDK9



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Fri Feb 24 18:47:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 18:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments collides in
 security domain service installing
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993045@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.82493.1487980020265@Atlassian.JIRA>

Jan Kalina created WFLY-8241:
--------------------------------

             Summary: EJB deployments collides in security domain service installing
                 Key: WFLY-8241
                 URL: https://issues.jboss.org/browse/WFLY-8241
             Project: WildFly
          Issue Type: Bug
          Components: EJB, Security
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Critical


Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107

But it fails if there are more such deployments, because it mean second service with the same name:
{code}
00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
	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 Feb 24 19:02:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 24 Feb 2017 19:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments collides in
 security domain service installing
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.82526.1487980920749@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369252#comment-13369252 ] 

Jan Kalina commented on WFLY-8241:
----------------------------------

[~fjuma], what was the intention here? Should be be added something to name of service (like deployment name or something) to prevent collisions?

> EJB deployments collides in security domain service installing
> --------------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 04:00:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 04:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.82671.1488013200764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-8241:
-----------------------------
    Summary: EJB deployments with Elytron SD collides in EJB3 SD service  (was: EJB deployments collides in security domain service installing)


> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 04:07:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 04:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.82705.1488013621282@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369252#comment-13369252 ] 

Jan Kalina edited comment on WFLY-8241 at 2/25/17 4:06 AM:
-----------------------------------------------------------

[~fjuma], what was the intention here? Should be be added something to name of service (like deployment name or something) to prevent collisions? Or should be service local somehow?


was (Author: honza889):
[~fjuma], what was the intention here? Should be be added something to name of service (like deployment name or something) to prevent collisions?

> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 13:27:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Feb 2017 13:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1507) Expose the ModelController
 via a capability
In-Reply-To: <JIRA.12616768.1461611433000@Atlassian.JIRA>
References: <JIRA.12616768.1461611433000@Atlassian.JIRA>
	<JIRA.12616768.1461611433000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616768.1461611433000.64.1488047220126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-1507:
----------------------------------------

    Assignee: Brian Stansberry


> Expose the ModelController via a capability
> -------------------------------------------
>
>                 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<ModelController>. 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  Sat Feb 25 13:28:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 25 Feb 2017 13:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1507) Expose the ModelController
 via a capability
In-Reply-To: <JIRA.12616768.1461611433000@Atlassian.JIRA>
References: <JIRA.12616768.1461611433000@Atlassian.JIRA>
	<JIRA.12616768.1461611433000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616768.1461611433000.69.1488047280097@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369320#comment-13369320 ] 

Brian Stansberry commented on WFCORE-1507:
------------------------------------------

Part of fixing WFCORE-2327 will be rationalizing a bit how internal clients are used, so I'm going to make WFCORE-1507 a part of that.

> Expose the ModelController via a capability
> -------------------------------------------
>
>                 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<ModelController>. 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  Sat Feb 25 19:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 19:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.99.1488068580441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-8241:
-----------------------------
    Steps to Reproduce: 
a) deploy attached EARs (read-props-limited.ear and read-props-grant.ear) in any order - second deploy will return described exception
b) using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}

  was:
a) using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}



> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 19:23:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 19:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.106.1488068580753@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-8241:
-----------------------------
    Steps to Reproduce: 
a) deploy attached EARs (read-props-limited.ear and read-props-grant.ear) in any order - second deploy will return described exception
b) alternative: using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}

  was:
a) deploy attached EARs (read-props-limited.ear and read-props-grant.ear) in any order - second deploy will return described exception
b) using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}



> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 19:26:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 19:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.120.1488068760669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-8241:
-----------------------------
    Attachment: enable-elytron.cli
                read-props-grant.ear
                read-props-limited.ear


> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sat Feb 25 19:26:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 25 Feb 2017 19:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.113.1488068760432@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-8241:
-----------------------------
    Steps to Reproduce: 
a) run *enable-elytron.cli* and *deploy* attached EARs (read-props-limited.ear and read-props-grant.ear) after (in any order) - second deployed will return described exception
b) alternative: using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}

  was:
a) deploy attached EARs (read-props-limited.ear and read-props-grant.ear) in any order - second deploy will return described exception
b) alternative: using testsuite with -Delytron: (ladybird branch of wildfly)
{code}
cd testsuite/integration/secman
mvn test -Delytron -Dtest=org.jboss.as.testsuite.integration.secman.propertypermission.EarModulesPPTestCase
{code}



> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Sun Feb 26 09:09:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 09:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.165.1488118140238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2327:
-------------------------------------
    Fix Version/s: 3.0.0.Beta6


> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 3.0.0.Beta6
>
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 09:37:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 09:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2327) embed-server froze during
 start when RBAC used
In-Reply-To: <JIRA.12678797.1487948431000@Atlassian.JIRA>
References: <JIRA.12678797.1487948431000@Atlassian.JIRA>
	<JIRA.12678797.1487948431000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678797.1487948431000.237.1488119820160@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369340#comment-13369340 ] 

Brian Stansberry commented on WFCORE-2327:
------------------------------------------

[~dlofthouse] I fixed this by cleaning up how in-VM ModelControllerClients are accessed, exposing a ModelControllerClientFactory as a capability. The factory has two methods for creating a client -- one that provides a client that always runs as superuser (using InVmAccess under the covers) and the other that does not. The existing internal client uses (Deployment scanner and offline CLI) use the SuperUser variant.

I don't want subsystem authors dealing with InVmAccess. That's internal. Hence the need for a factory that provides a suitable client for purely in-vm activity that should have SuperUser perms.

However, this "super user client" does not internally wrap its calls with AccessController.doPrivileged. So, in a security manager enabled VM, the code using the client will need to have ControllerPermission.PERFORM_IN_VM_CALL. This forces the code author to consider whether they are using the client appropriately.

For the deployment scanner, I wrapped its calls to "super user client" in a doPrivileged. (As you already had in your earlier work on this.)

For the offline CLI, I did not. This means that in a security manager environment offline CLI users will need permissions configured. 

> embed-server froze during start when RBAC used
> ----------------------------------------------
>
>                 Key: WFCORE-2327
>                 URL: https://issues.jboss.org/browse/WFCORE-2327
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 3.0.0.Alpha17
>            Reporter: Jan Kalina
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 3.0.0.Beta6
>
>         Attachments: standalone.xml
>
>
> When RBAC enabled, embed-server froze during start - CLI prompt of started server does not show and need to be interrupted by Ctrl+C.
> {code}
> bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server --std-out=echo
> 15:55:41,588 INFO  [org.jboss.modules] (AeshProcess: 1) JBoss Modules version 1.6.0.Beta3
> 15:55:41,650 INFO  [org.jboss.msc] (AeshProcess: 1) JBoss MSC version 1.2.7.Final
> 15:55:41,773 INFO  [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" starting
> 15:55:41,966 INFO  [org.jboss.as.domain.management] (MSC service thread 1-4) WFLYDM0136: Registered OpenSSL provider
> 15:55:42,302 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.
> 15:55:42,367 INFO  [org.jboss.as.patching] (MSC service thread 1-8) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> 15:55:42,386 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-4) WFLYDM0111: Keystore /home/jkalina/wildfly/wildfly-core/build/target/wildfly-core-3.0.0.Alpha18-SNAPSHOT/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> 15:55:42,466 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0212: Resuming server
> 15:55:42,469 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha18-SNAPSHOT "Kenny" started in 875ms - Started 37 of 46 services (17 services are lazy, passive or on-demand)
> {code}
> In this stage it froze and need to be interrupted by Ctrl+C.
> {code}
> Interrupted while waiting for embedded server to start
> [disconnected /]
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 13:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 13:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2329) ServerAutoStartTestCase and
 ServerStartFailureTestCase are never run
In-Reply-To: <JIRA.12678929.1488133515000@Atlassian.JIRA>
References: <JIRA.12678929.1488133515000@Atlassian.JIRA>
	<JIRA.12678929.1488133515064@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678929.1488133515000.257.1488133560076@Atlassian.JIRA>

Brian Stansberry created WFCORE-2329:
----------------------------------------

             Summary: ServerAutoStartTestCase and ServerStartFailureTestCase are never run
                 Key: WFCORE-2329
                 URL: https://issues.jboss.org/browse/WFCORE-2329
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Test Suite
            Reporter: Brian Stansberry


Tests in testsuite/domain do not all automatically run just by being called XXXTestCase. They need to be located in one of the packages listed in the surefire config in testsuite/domain/pom.xml or by listed in the @Suite.SuiteClasses annotation of one of the suites that is in one of those packages. ServerAutoStartTestCase and ServerStartFailureTestCase are tests where neither of these are true so they are not running.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 13:44:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 13:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2320) Unable to start Slave host
 after Master was restarted with enabled RBAC
In-Reply-To: <JIRA.12678458.1487844263000@Atlassian.JIRA>
References: <JIRA.12678458.1487844263000@Atlassian.JIRA>
	<JIRA.12678458.1487844263000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678458.1487844263000.306.1488134640342@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2320:
-------------------------------------
    Fix Version/s: 3.0.0.Beta6


> Unable to start Slave host after Master was restarted with enabled RBAC
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2320
>                 URL: https://issues.jboss.org/browse/WFCORE-2320
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Jan Tymel
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta6
>
>
> It is not possible to connect to previously shutdown domain controller that uses RBAC. If steps to reproduce are followed then the following output is given on slave:
> {code}
> [Host Controller] 10:47:57,754 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:01,756 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:10,918 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:26,026 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:41,047 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:48:56,059 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:11,106 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:26,133 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:41,148 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:49:56,180 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:11,202 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:26,215 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:41,230 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,264 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:50:56,273 WARN  [org.jboss.as.protocol.connection] (management task-1) WFLYPRT0018: No such request (15) associated with channel Channel ID ce1200c8 (outbound) of Remoting connection 6cf4e35b to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> [Host Controller] 10:51:11,275 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:51:11,304 WARN  [org.jboss.as.protocol.connection] (management task-7) WFLYPRT0018: No such request (16) associated with channel Channel ID cabd84e6 (outbound) of Remoting connection 3083f850 to /127.0.0.1:9999 of endpoint "my-local-domain:MANAGEMENT" <988a70d>
> (...)
> Host Controller] 10:52:26,401 INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 8) WFLYHC0150: Trying to reconnect to master host controller.
> [Host Controller] 10:52:40,194 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:40,196 ERROR [org.jboss.as.server] (Host Controller Service Threads - 7) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> On master instance is given following output after a while:
> {code}
> [Host Controller] 10:52:59,560 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0313: Unauthorized to execute operation 'read-attribute' for resource '[]' -- "WFLYCTL0332: Permission denied" 
> [Host Controller] 10:52:59,564 ERROR [org.jboss.as.server] (Host Controller Service Threads - 31) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0031: No operation named 'clean-obsolete-content' exists at address []
> {code}
> Once the slave instance has been shut down, it is not possible to start it again. See following output:
> {code}
> [Host Controller] 10:55:34,409 INFO  [org.jboss.as.remoting] (MSC service thread 1-2) WFLYRMT0001: Listening on 127.0.0.1:19999
> [Host Controller] 10:55:34,701 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0001: Could not connect to remote domain controller remote://127.0.0.1:9999: 1-$-WFLYCTL0216: Management resource '[]' not found
> [Host Controller] 	at org.jboss.as.host.controller.RemoteDomainConnection$HostControllerConnectRequest.handleRequest(RemoteDomainConnection.java:390)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:321)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleRequest(AbstractMessageHandler.java:286)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:234)
> [Host Controller] 	at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:85)
> [Host Controller] 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> [Host Controller] 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:817)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] 	at java.lang.Thread.run(Thread.java:745)
> [Host Controller] 
> [Host Controller] 10:55:34,702 WARN  [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0147: No domain controller discovery options remain.
> [Host Controller] 10:55:34,702 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0002: Could not connect to master. Error was: java.lang.IllegalStateException: WFLYHC0120: Tried all domain controller discovery option(s) but unable to connect
> [Host Controller] 10:55:34,707 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
> [Host Controller] 10:55:34,734 INFO  [org.jboss.as] (MSC service thread 1-4) WFLYSRV0050: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Beta2-redhat-1) stopped in 16ms
> {code}
> Setting priority to blocker since this is a regression against 7.0.0.GA



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 13:51:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 13:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.311.1488135060187@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369348#comment-13369348 ] 

Brian Stansberry commented on WFCORE-1958:
------------------------------------------

[~dlofthouse] I'm not sure what needs to be done here, but for my work on WFCORE-2320 I reenabled a large number of tests in testsuite/domain that were @Ignored with a ref to this JIRA. I left the @Ignore, just commented out, so it's still possible to find those items by grepping for "WFCORE-1958".

I enabled them because they pass now and we need the test coverage.

In testsuite/manualmode org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase is still ignored, since it doesn't pass.

> 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.Beta6
>
>
> 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  Sun Feb 26 13:55:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sun, 26 Feb 2017 13:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.318.1488135300277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369349#comment-13369349 ] 

Brian Stansberry commented on WFCORE-1964:
------------------------------------------

I believe my work on WFCORE-1507 and WFCORE-2327 resolves this issue: https://github.com/wildfly/wildfly-core/pull/2205

> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 3.0.0.Beta6
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 15:40:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Sun, 26 Feb 2017 15:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8242)
	EjbSuspendHandler.endSuspension throws NPE
In-Reply-To: <JIRA.12678932.1488141594000@Atlassian.JIRA>
References: <JIRA.12678932.1488141594000@Atlassian.JIRA>
	<JIRA.12678932.1488141594061@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678932.1488141594000.342.1488141600074@Atlassian.JIRA>

Flavia Rainone created WFLY-8242:
------------------------------------

             Summary: EjbSuspendHandler.endSuspension throws NPE
                 Key: WFLY-8242
                 URL: https://issues.jboss.org/browse/WFLY-8242
             Project: WildFly
          Issue Type: Bug
          Components: EJB
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


This exception occurs sometimes:
java.lang.NullPointerException
        at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.doneSuspended(EJBSuspendHandlerService.java:303) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.decrementTransactionCount(EJBSuspendHandlerService.java:315) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.as.ejb3.suspend.EJBSuspendHandlerService.afterCompletion(EJBSuspendHandlerService.java:285) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
        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) [wildfly-transaction-client-1.0.0.Beta17.jar:1.0.0.Beta17]
        at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:61) [wildfly-transaction-client-1.0.0.Beta17.jar:1.0.0.Beta17]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-7.1.0.Alpha1-redhat-SNAPSHOT.jar:7.1.0.Alpha1-redhat-SNAPSHOT]




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 16:27:00 2017
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Sun, 26 Feb 2017 16:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8243) Clustered Singleton MDB does
	not activate
In-Reply-To: <JIRA.12678933.1488144117000@Atlassian.JIRA>
References: <JIRA.12678933.1488144117000@Atlassian.JIRA>
	<JIRA.12678933.1488144117000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678933.1488144117000.414.1488144420357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone moved JBEAP-9130 to WFLY-8243:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8243  (was: JBEAP-9130)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                       EJB
                       JMS
                           (was: Clustering)
                           (was: EJB)
                           (was: JMS)
    Affects Version/s:     (was: 7.1.0.DR8)
                           (was: 7.1.0.DR10)
                           (was: 7.1.0.DR11)
                           (was: 7.1.0.DR12)
      Affects Testing:   (was: Regression)


> Clustered Singleton MDB does not activate
> -----------------------------------------
>
>                 Key: WFLY-8243
>                 URL: https://issues.jboss.org/browse/WFLY-8243
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB, JMS
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>            Priority: Blocker
>
> Clustered Singleton MDB does not activate. It's regression in EAP 7.1.0.DR8 (against DR7).
> Customer impact: No Clustered Singleton MDB will activate in cluster and service will not operate. No warning or error will show in server logs. There is no workaround for this issue. 
> Test scenario:
> - Start two EAP 7.1.0.DR8 servers in cluster with active delivery-group named "group" 
> - Deploy queues InQueue and OutQueue to both of the servers. There is also Artemis cluster configured between servers so all messages will be load-balanced between the nodes.
> - Deploy MDB configured as clustered singletons to both of the server. MDBs belong to delivery-group "group"
> -- MDB consumes messages from InQueue and resends to OutQueue
> - Start sending messages to InQueue and consume from OutQueue.
> - Check that MDB on node 1 is active as it's sigleton master
> - Check that MDB on node 2 is NOT active 
> - Kill node-1 (by kill -9 ...)
> - Check that MDB on node 2 is active as it's sigleton master
> Expected result:
> Consumer will receive all messages from OutQueue. All checks passes.
> Actual result:
> MDB on node 1 is not delivery active at the beginning of the test. Consumer timed out as there are no processed messages in OutQueue



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 18:16:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Feb 2017 18:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.505.1488150960622@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369370#comment-13369370 ] 

Edson Tirelli commented on DROOLS-1432:
---------------------------------------

Major infrastructure changes to properly support error validation are now implemented. Type definition and resolution is now correlated between DMN layer and FEEL layer. Additional work will be done through other tickets.

> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 18:16:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Feb 2017 18:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1432) Improve error messages when
 compiling models with errors
In-Reply-To: <JIRA.12675833.1486665303000@Atlassian.JIRA>
References: <JIRA.12675833.1486665303000@Atlassian.JIRA>
	<JIRA.12675833.1486665303000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675833.1486665303000.508.1488150960695@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-1432:
----------------------------------
    Release Notes Text:   (was: Major infrastructure changes to properly support error validation are now implemented. Type definition and resolution is now correlated between DMN layer and FEEL layer. Additional work will be done through other tickets.)


> Improve error messages when compiling models with errors
> --------------------------------------------------------
>
>                 Key: DROOLS-1432
>                 URL: https://issues.jboss.org/browse/DROOLS-1432
>             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
>
>         Attachments: car_damage_responsibility2.dmn
>
>
> When a model contains errors that prevent compilation, the engine should provide a better error message pointing to the specific error.
> At the moment, the attached model fails with a NPE and a message:
> {quote}Message [id=1, kieBase=defaultKieBase, level=ERROR, path=car_damage_responsibility2.dmn, line=-1, column=0 text=Unable to compile DMN model for the resource]{quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 18:16:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Sun, 26 Feb 2017 18:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1436) Unable to create runtime
 for the attached DMN model
In-Reply-To: <JIRA.12676071.1486763915000@Atlassian.JIRA>
References: <JIRA.12676071.1486763915000@Atlassian.JIRA>
	<JIRA.12676071.1486763915000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676071.1486763915000.512.1488150960930@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved DROOLS-1436.
-----------------------------------
    Resolution: Done


> Unable to create runtime for the attached DMN model
> ---------------------------------------------------
>
>                 Key: DROOLS-1436
>                 URL: https://issues.jboss.org/browse/DROOLS-1436
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: M?lanie Gauthier
>            Assignee: Edson Tirelli
>         Attachments: Get Viable Loan Products.dmn
>
>
> When trying to load that model, the following errors is logged:
>  java.lang.IllegalStateException: [Message [id=1, kieBase=defaultKieBase, level=ERROR, path=trisotech/Get_Viable_Loan_Products.dmn, line=-1, column=0
>    text=Unable to compile DMN model for the resource]]



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Sun Feb 26 20:23:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Sun, 26 Feb 2017 20:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2330) JBoss-CLI "deploy -l"
 always returns exit code 1 even when it succeeds
In-Reply-To: <JIRA.12678941.1488158533000@Atlassian.JIRA>
References: <JIRA.12678941.1488158533000@Atlassian.JIRA>
	<JIRA.12678941.1488158533721@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678941.1488158533000.560.1488158580114@Atlassian.JIRA>

Masafumi Miura created WFCORE-2330:
--------------------------------------

             Summary: JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
                 Key: WFCORE-2330
                 URL: https://issues.jboss.org/browse/WFCORE-2330
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Masafumi Miura


JBoss-CLI "deploy -l" always returns exit code 1 even when it succeededs.

It looks that DeploymentHandler.listDeployments() always throws CommandFormatException and this causes the "deploy -l" command returns exit code 1.

{code:java|title=cli/src/main/java/org/jboss/as/cli/handlers/DeploymentHandler.java}
 55     protected void listDeployments(CommandContext ctx, boolean l) throws CommandFormatException {
 56         if(!l) {
 57             printList(ctx, Util.getDeployments(ctx.getModelControllerClient()), l);
 58             return;
 59         }
 60         final ModelControllerClient client = ctx.getModelControllerClient();
 61         final List<String> names = Util.getDeployments(client);
 62         if(names.isEmpty()) {
 63             return;
 64         }
 65 
 66         final StrictSizeTable table = new StrictSizeTable(names.size());
 67         final List<Property> descriptions = getDeploymentDescriptions(ctx, names).asPropertyList();
 68         for(Property prop : descriptions) {
 69             final ModelNode step = prop.getValue();
 70             if(step.hasDefined(Util.RESULT)) {
 71                 final ModelNode result = step.get(Util.RESULT);
 72                 table.addCell(Util.NAME, result.get(Util.NAME).asString());
 73                 table.addCell(Util.RUNTIME_NAME, result.get(Util.RUNTIME_NAME).asString());
 74                 if(result.has(Util.ENABLED)) {
 75                     table.addCell(Util.ENABLED, result.get(Util.ENABLED).asString());
 76                 }
 77                 if(result.has(Util.STATUS)) {
 78                     table.addCell(Util.STATUS, result.get(Util.STATUS).asString());
 79                 }
 80             }
 81             if(!table.isAtLastRow()) {
 82                 table.nextRow();
 83             }
 84         }
 85         throw new CommandFormatException(table.toString());   // -> CommandFormatException is always thrown. This looks a root cause.
 86     }
{code}

{code:java|title=cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java}
 907     public void handleSafe(String line) {
 908         exitCode = 0;
 909         try {
 910             handle(line);
 911         } catch(Throwable t) {
 912             error(Util.getMessagesFromThrowable(t));   // -> This is invoked when CommandFormatException happened in the above listDeployments. 
 913         }
 914     }
  :
 993     protected void error(String message) {
 994         this.exitCode = 1;
 995         printLine(message);
 996     }
{code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 20:46:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Sun, 26 Feb 2017 20:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2331) When --cached-dc used HC
 does not inform on configuration change if DC reconnection happens
In-Reply-To: <JIRA.12678942.1488159886000@Atlassian.JIRA>
References: <JIRA.12678942.1488159886000@Atlassian.JIRA>
	<JIRA.12678942.1488159886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678942.1488159886000.589.1488159960164@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills moved JBEAP-9133 to WFCORE-2331:
------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2331  (was: JBEAP-9133)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Domain Management)
    Affects Version/s:     (was: 7.1.0.DR11)


> When --cached-dc used HC does not inform on configuration change if DC reconnection happens
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2331
>                 URL: https://issues.jboss.org/browse/WFCORE-2331
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> HC does not inform that DC changed configuration and reload/restart is required when `--cached-dc` is used.
> This issue was created based on discussion at https://issues.jboss.org/browse/EAP7-496.
> HC starts with `--cached-dc` and DC is down. If DC contains changed attribute and is started HC receives configuration updates that was changed in comparison to existing 
> "domain.cached-remote.xml". The change seems to be propagated to HC but it's not "activated" (it's not part of model at HC) neither information that reload/restart of HC is needed is provided.
> This could be checked with following steps
> # start DC and HC with {{--cached-dc}} parameter
>  {code}
>  cd $JBOSS_HOME
>  ./bin/domain.sh --host-config=host-master.xml
>  ./bin/domain.sh  --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=9899 -Djboss.host.name=slave --cached-dc
>  {code}
> # stop HC
> # configure logging at DC
>  {code}
>  cd $JBOSS_HOME
>  ./bin/jboss-cli.sh -c
>  /profile=full/subsystem=logging/logger=my.test:add(category=my.test, level=FINE)
>  {code}
> # stop DC
> # start HC
>  {code}
>  ./bin/domain.sh  --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1 -Djboss.management.native.port=9899 -Djboss.host.name=slave --cached-dc
>  {code}
> # check that logging is not configured
>  {code}
>  ./bin/jboss-cli.sh -c --controller=remoting://localhost:9899
>  /host=slave/server=server-one/subsystem=logging:read-children-resources(child-type=logger)
>  {code}
> # start DC and wait a while when HC is connected to it
>  {code}
>  INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 33) WFLYHC0150: Trying to reconnect to master host controller.
>  INFO  [org.jboss.as.host.controller] (Host Controller Service Threads - 33) WFLYHC0148: Connected to master host controller at remote://127.0.0.1:9999
>  {code}
> # check what DC says about server-one
>  {code}
>  ./bin/jboss-cli.sh -c
>  /host=slave/server=server-one/subsystem=logging:read-children-resources(child-type=logger)
>  {code}
> The result is that the new logger {{my.test}} is not part of the configuration of {{server-one}}. There is no warning about such fact in server log what I can see.
> True is that here behaves differently against my testing before that after printing resources of the subsystem {{logging}} node there is information {{reload-required}}.
> From your point of view - is this correct behavior? If so I think some warning message in server log at least that content of {{domain.cached-remote.xml}} is not in sync with servers' model should be promoted.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Sun Feb 26 20:46:00 2017
From: issues at jboss.org (Masafumi Miura (JIRA))
Date: Sun, 26 Feb 2017 20:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2330) JBoss-CLI "deploy -l"
 always returns exit code 1 even when it succeeds
In-Reply-To: <JIRA.12678941.1488158534000@Atlassian.JIRA>
References: <JIRA.12678941.1488158534000@Atlassian.JIRA>
	<JIRA.12678941.1488158534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678941.1488158534000.593.1488159960345@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Masafumi Miura updated WFCORE-2330:
-----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2207


> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-2330
>                 URL: https://issues.jboss.org/browse/WFCORE-2330
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Masafumi Miura
>
> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeededs.
> It looks that DeploymentHandler.listDeployments() always throws CommandFormatException and this causes the "deploy -l" command returns exit code 1.
> {code:java|title=cli/src/main/java/org/jboss/as/cli/handlers/DeploymentHandler.java}
>  55     protected void listDeployments(CommandContext ctx, boolean l) throws CommandFormatException {
>  56         if(!l) {
>  57             printList(ctx, Util.getDeployments(ctx.getModelControllerClient()), l);
>  58             return;
>  59         }
>  60         final ModelControllerClient client = ctx.getModelControllerClient();
>  61         final List<String> names = Util.getDeployments(client);
>  62         if(names.isEmpty()) {
>  63             return;
>  64         }
>  65 
>  66         final StrictSizeTable table = new StrictSizeTable(names.size());
>  67         final List<Property> descriptions = getDeploymentDescriptions(ctx, names).asPropertyList();
>  68         for(Property prop : descriptions) {
>  69             final ModelNode step = prop.getValue();
>  70             if(step.hasDefined(Util.RESULT)) {
>  71                 final ModelNode result = step.get(Util.RESULT);
>  72                 table.addCell(Util.NAME, result.get(Util.NAME).asString());
>  73                 table.addCell(Util.RUNTIME_NAME, result.get(Util.RUNTIME_NAME).asString());
>  74                 if(result.has(Util.ENABLED)) {
>  75                     table.addCell(Util.ENABLED, result.get(Util.ENABLED).asString());
>  76                 }
>  77                 if(result.has(Util.STATUS)) {
>  78                     table.addCell(Util.STATUS, result.get(Util.STATUS).asString());
>  79                 }
>  80             }
>  81             if(!table.isAtLastRow()) {
>  82                 table.nextRow();
>  83             }
>  84         }
>  85         throw new CommandFormatException(table.toString());   // -> CommandFormatException is always thrown. This looks a root cause.
>  86     }
> {code}
> {code:java|title=cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java}
>  907     public void handleSafe(String line) {
>  908         exitCode = 0;
>  909         try {
>  910             handle(line);
>  911         } catch(Throwable t) {
>  912             error(Util.getMessagesFromThrowable(t));   // -> This is invoked when CommandFormatException happened in the above listDeployments. 
>  913         }
>  914     }
>   :
>  993     protected void error(String message) {
>  994         this.exitCode = 1;
>  995         printLine(message);
>  996     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 01:53:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 27 Feb 2017 01:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8244) Changing management interface
 with allow-resource-service-restart ends in reload-required state
In-Reply-To: <JIRA.12678949.1488178346000@Atlassian.JIRA>
References: <JIRA.12678949.1488178346000@Atlassian.JIRA>
	<JIRA.12678949.1488178346972@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678949.1488178346000.821.1488178380149@Atlassian.JIRA>

Martin Choma created WFLY-8244:
----------------------------------

             Summary: Changing management interface with allow-resource-service-restart ends in reload-required state
                 Key: WFLY-8244
                 URL: https://issues.jboss.org/browse/WFLY-8244
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


If I try to change elytron authentication for management interface with header {{allow-resource-service-restart=true}} server ends in {{reload-required}} state. 

{code}
[standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-http-authentication){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. 
If it can't be implemented for some reason, rather throw UnsupportedOperationException - it seems to me to be more fair.




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 02:45:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Feb 2017 02:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.933.1488181500281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13368041#comment-13368041 ] 

Bela Ban edited comment on JGRP-2159 at 2/27/17 2:44 AM:
---------------------------------------------------------

Workaround: {{GMS.use_delta_views="false"}} or {{GMS.install_view_locally_first="true"}}


was (Author: belaban):
Workaround: {{GMS.use_delta_views="false"}}

> 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  Mon Feb 27 03:03:00 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 27 Feb 2017 03:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.986.1488182580113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369414#comment-13369414 ] 

Bela Ban commented on JGRP-2159:
--------------------------------

Here's how this can be reproduced (unit test: {{DeltaViewTest}}):
* J is the coordinator and has view J|0=K
* K joins and sends a JOIN-REQ to J
* J creates new view J|1=J,K (setting {{ltime}} to 1) and multicasts it, but the multicast is delayed (e.g. dropped and retransmitted)
* Finally, J sends a JOIN-RSP with view J|1 to K
* Before receiving the new view, K times out and sends another JOIN-REQ to J
* K receives view J|1 and installs it
* J creates a new view J|2=J,K (setting {{ltime}} to 2) and multicasts it. The multicast is again delayed.
* J sends a JOIN-RSP to K with view J|2, K installs it
* J finally gets the first view multicast and installs J|1=J,K
* New member L sends a JOIN-RSP to J
* J creates view J|3=JKL and multicasts it, and then sends a JOIN-RSP to L
* The multicast of J|3 is a *DeltaView* with ref-view-id=J|1 and joiners=L
* L installs the new view
* J installs the new view J|3
* However, K cannot install the new view as ref-view-id=J|1 is not known as it has view=J|2!

SOLUTION:
* The reason why spurious view J|2 is sent to K is that J hasn't yet installed view J|1 locally. If that was the case, it would see that K is already a member and simply resend view J|1, instead of creating view J|2.
* We therefore need to make sure a new view is installed in the coordinator *before* multicasting it, and this can be done by setting {{install_view_locally_first}} to true by default (or even removing the attribute)
* As a second line of defense, make the recepient of a DeltaView that cannot be installed send a request to the coordinator to resend the view as a full- instead of a delta- view.

* J creates new view J|3=JL

> 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  Mon Feb 27 03:05:01 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 27 Feb 2017 03:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8074) JCA1.7
 MessageEndpointFactory.getActivationName() returns null
In-Reply-To: <JIRA.12675978.1486734612000@Atlassian.JIRA>
References: <JIRA.12675978.1486734612000@Atlassian.JIRA>
	<JIRA.12675978.1486734612000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675978.1486734612000.1020.1488182701013@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369415#comment-13369415 ] 

Ivo Studensky commented on WFLY-8074:
-------------------------------------

test-case:
https://github.com/istudens/wildfly/commit/731ebbff0618eff2432c961d875c5cc10c9b8c4f

> JCA1.7 MessageEndpointFactory.getActivationName() returns null
> --------------------------------------------------------------
>
>                 Key: WFLY-8074
>                 URL: https://issues.jboss.org/browse/WFLY-8074
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> As per JCA 1.7 spec. and JavaDoc, it should return "a new String instance representing the unique name of the message endpoint deployment". However, it returns null.
> JCA 1.7 and was implemented in IronJacamar via https://issues.jboss.org/browse/JBJCA-983 and is described in http://www.ironjacamar.org/doc/api/spec/1.7/javax/resource/spi/endpoint/MessageEndpointFactory.html
> Based on latest code at https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java
> * there is a getActivationName() method but no setActivationName(Sting xyz) method
> * Private variable activationName.defined but never set
> * not set in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/inflow/JBossMessageEndpointFactory.java either



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 03:21:02 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 27 Feb 2017 03:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8245) AuthenticationContext should
 not be loaded from wildfly-config.xml automatically in deployment
In-Reply-To: <JIRA.12678958.1488183634000@Atlassian.JIRA>
References: <JIRA.12678958.1488183634000@Atlassian.JIRA>
	<JIRA.12678958.1488183634585@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678958.1488183634000.1092.1488183662262@Atlassian.JIRA>

Ondrej Lukas created WFLY-8245:
----------------------------------

             Summary: AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
                 Key: WFLY-8245
                 URL: https://issues.jboss.org/browse/WFLY-8245
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse
            Priority: Critical


In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.

This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).

In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.

If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.

[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 03:21:03 2017
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Mon, 27 Feb 2017 03:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8245) AuthenticationContext should
 not be loaded from wildfly-config.xml automatically in deployment
In-Reply-To: <JIRA.12678958.1488183635000@Atlassian.JIRA>
References: <JIRA.12678958.1488183635000@Atlassian.JIRA>
	<JIRA.12678958.1488183635000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678958.1488183635000.1101.1488183663249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-8245:
-------------------------------
    Description: 
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.

In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.

If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.

[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?

  was:
In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.

This behavior was changed between EAP 7.1.0.DR11 and EAP 7.1.0.DR12 (try Steps to Reproduce with DR12 as well as DR11).

In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.

If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.

[~dlofthouse] Could you please clarify whether this is intended change or it is an issue?



> AuthenticationContext should not be loaded from wildfly-config.xml automatically in deployment
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8245
>                 URL: https://issues.jboss.org/browse/WFLY-8245
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>            Priority: Critical
>
> In case when wildfly-config.xml is located in deployment and application server does not have configured default-authentication-context for Elytron subsystem, then AuthenticationContext is automatically parsed from wildfly-config.xml.
> In case when default-authentication-context for Elytron subsystem is configured, then AuthenticationContext is correctly loaded from application server.
> If this is intended then it should be reflect in documentation - it currently says that "... they can make use of a configuration file using the _parseAuthenticationClientConfiguration(URI)_ method ...", but in current implementation it is parsed automatically.
> [~dlofthouse] Could you please clarify whether this is intended change or it is an issue?



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 03:38:01 2017
From: issues at jboss.org (Khuddus Abdul (JIRA))
Date: Mon, 27 Feb 2017 03:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6695) JspTagTestCase fails on
	Windows
In-Reply-To: <JIRA.12630419.1465485615000@Atlassian.JIRA>
References: <JIRA.12630419.1465485615000@Atlassian.JIRA>
	<JIRA.12630419.1465485615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630419.1465485615000.1189.1488184681212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369430#comment-13369430 ] 

Khuddus Abdul commented on WFLY-6695:
-------------------------------------

Facing the same issue.

> JspTagTestCase fails on Windows
> -------------------------------
>
>                 Key: WFLY-6695
>                 URL: https://issues.jboss.org/browse/WFLY-6695
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.CR1
>         Environment: Windows 10, Oracle JDK 1.8.0_92
>            Reporter: Frank Langelage
>
> build.bat clean install failed with
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.jsp.JspTagTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.768 sec <<< FAILURE! - in org.jboss.as.test.integration.jsp.JspTagTestCase
> test(org.jboss.as.test.integration.jsp.JspTagTestCase)  Time elapsed: 0.486 sec  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<This is a header[
> <div>tag</div>
> Static content]
> > but was:<This is a header[
> <div>tag</div>
> Static content
> ]
> >
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.test.integration.jsp.JspTagTestCase.test(JspTagTestCase.java:67)
> Replacing all occurence of "\n" with System.getProperty("line.separator") in the expected String solved the problem for me.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 03:48:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 03:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8246) Colocated HA topology doesn't
 work with HTTP connectors and static cluster
In-Reply-To: <JIRA.12678961.1488185250000@Atlassian.JIRA>
References: <JIRA.12678961.1488185250000@Atlassian.JIRA>
	<JIRA.12678961.1488185250000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678961.1488185250000.1268.1488185280589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-9143 to WFLY-8246:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8246  (was: JBEAP-9143)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: JMS)
    Affects Version/s:     (was: 7.1.0.DR12)
      Affects Testing:   (was: Regression)


> Colocated HA topology doesn't work with HTTP connectors and static cluster
> --------------------------------------------------------------------------
>
>                 Key: WFLY-8246
>                 URL: https://issues.jboss.org/browse/WFLY-8246
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> *Scenario:*
> * 2 EAPs configured in colocated shared store HA topology with HTTP connectors and static cluster
> * static cluster means that cluster-connection is defined by static-connectors property
> * both EAPs and standalone clients are started
> * after that receiver receives 120 messages, first EAP is shut down
> *Expectation:* Clients do failover to second EAP and continue in their work.
> *Reality*: Clients are not able to reconnect to backup server.
> During the whole test I see a lot of {{AMQ214023: HTTP Handshake failed}} errors.
> The same scenario works with Netty connectors.
> The same scenario works in dedicated topology.
> Priority of this issue is blocker because it is regression against previous versions of EAP 7.1.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 04:20:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 27 Feb 2017 04:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5966) Validate requirement for
 modules previously exported by javax.ejb.api
In-Reply-To: <JIRA.12598770.1452285429000@Atlassian.JIRA>
References: <JIRA.12598770.1452285429000@Atlassian.JIRA>
	<JIRA.12598770.1452285429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12598770.1452285429000.1399.1488187200347@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369445#comment-13369445 ] 

Martin Kouba commented on WFLY-5966:
------------------------------------

It should be safe to remove the depndencies from the {{org.jboss.weld.core}} module (feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml). Weld subsystem module.xml does not contain the dependencies any more.

Note that this "blind addition" significantly affects the size of  WildFly Swarm uberjar because {{org.omg.api}} depends on {{org.jboss.jts}} -> {{org.apache.activemq.artemis}} -> {{org.wildfly.extension.messaging-activemq}} -> {{org.jboss.as.weld}} etc etc.. So once you add any of the modules mentioned above the size grows significantly (brings EJB3, Hibernate, etc.).

> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
>                 Key: WFLY-5966
>                 URL: https://issues.jboss.org/browse/WFLY-5966
>             Project: WildFly
>          Issue Type: Task
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Jason Greene
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
>         <!-- TODO validate the need for these and remove if not needed.
>              Prior to WFLY-5922 they were exported by javax.ejb.api. -->
>         <module name="javax.api"/>
>         <module name="javax.transaction.api"/>
>         <module name="javax.xml.rpc.api"/>
>         <module name="javax.rmi.api"/>
>         <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml        
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml        
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml        
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml        
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml        
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/jberet/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
>  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 04:45:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 04:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8247) Unable to send large message
 if JDBC-persistance-store is used
In-Reply-To: <JIRA.12678969.1488188668000@Atlassian.JIRA>
References: <JIRA.12678969.1488188668000@Atlassian.JIRA>
	<JIRA.12678969.1488188668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678969.1488188668000.1671.1488188701227@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-9145 to WFLY-8247:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8247  (was: JBEAP-9145)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: ActiveMQ)
                           (was: JMS)
    Affects Version/s:     (was: 7.1.0.DR8)
                           (was: 7.1.0.DR9)
                           (was: 7.1.0.DR10)
                           (was: 7.1.0.DR11)
                           (was: 7.1.0.DR12)
      Affects Testing:   (was: Blocks Testing)


> Unable to send large message if JDBC-persistance-store is used
> --------------------------------------------------------------
>
>                 Key: WFLY-8247
>                 URL: https://issues.jboss.org/browse/WFLY-8247
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>         Environment: The issue was hit with Oracle 12c database
>            Reporter: Jeff Mesnil
>            Assignee: Martyn Taylor
>            Priority: Blocker
>
> If producer sends large message to EAP with JDBC-persistance store, the following error arises on the server.
> {code}
> 11:49:34,248 ERROR [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ224016: Caught exception: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=Invalid conversion requested]
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:458)
> 	at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.sendLarge(ServerSessionImpl.java:1189)
> 	at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:436)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> Caused by: java.sql.SQLException: Invalid conversion requested
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:832)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getNUMBER(T4CVarcharAccessor.java:239)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getInt(T4CVarcharAccessor.java:527)
> 	at oracle.jdbc.driver.GeneratedStatement.getInt(GeneratedStatement.java:217)
> 	at oracle.jdbc.driver.GeneratedScrollableResultSet.getInt(GeneratedScrollableResultSet.java:573)
> 	at org.jboss.jca.adapters.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:1490)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createFile(JDBCSequentialFileFactoryDriver.java:165)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.openFile(JDBCSequentialFileFactoryDriver.java:102)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.open(JDBCSequentialFile.java:98)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:391)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:370)
> 	... 21 more
> Caused by: java.lang.NumberFormatException
> 	at java.math.BigDecimal.<init>(BigDecimal.java:494) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:383) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:806) [rt.jar:1.8.0_111]
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:825)
> 	... 31 more
> {code}
> *Customer impact*: Clients are not able to send large messages. Sending/receiving large messages is common customer use case. This blocks RFE EAP7-591.
> There is no workaround. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 04:45:01 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 04:45:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8247) Unable to send large message
 if JDBC-persistance-store is used
In-Reply-To: <JIRA.12678969.1488188668000@Atlassian.JIRA>
References: <JIRA.12678969.1488188668000@Atlassian.JIRA>
	<JIRA.12678969.1488188668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678969.1488188668000.1676.1488188701365@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-8247:
---------------------------------

    Assignee: Jeff Mesnil  (was: Martyn Taylor)


> Unable to send large message if JDBC-persistance-store is used
> --------------------------------------------------------------
>
>                 Key: WFLY-8247
>                 URL: https://issues.jboss.org/browse/WFLY-8247
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>         Environment: The issue was hit with Oracle 12c database
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> If producer sends large message to EAP with JDBC-persistance store, the following error arises on the server.
> {code}
> 11:49:34,248 ERROR [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ224016: Caught exception: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=Invalid conversion requested]
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:458)
> 	at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.sendLarge(ServerSessionImpl.java:1189)
> 	at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:436)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> Caused by: java.sql.SQLException: Invalid conversion requested
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:832)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getNUMBER(T4CVarcharAccessor.java:239)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getInt(T4CVarcharAccessor.java:527)
> 	at oracle.jdbc.driver.GeneratedStatement.getInt(GeneratedStatement.java:217)
> 	at oracle.jdbc.driver.GeneratedScrollableResultSet.getInt(GeneratedScrollableResultSet.java:573)
> 	at org.jboss.jca.adapters.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:1490)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createFile(JDBCSequentialFileFactoryDriver.java:165)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.openFile(JDBCSequentialFileFactoryDriver.java:102)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.open(JDBCSequentialFile.java:98)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:391)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:370)
> 	... 21 more
> Caused by: java.lang.NumberFormatException
> 	at java.math.BigDecimal.<init>(BigDecimal.java:494) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:383) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:806) [rt.jar:1.8.0_111]
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:825)
> 	... 31 more
> {code}
> *Customer impact*: Clients are not able to send large messages. Sending/receiving large messages is common customer use case. This blocks RFE EAP7-591.
> There is no workaround. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 04:47:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 04:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8247) Unable to send large message
 if JDBC-persistance-store is used
In-Reply-To: <JIRA.12678969.1488188668000@Atlassian.JIRA>
References: <JIRA.12678969.1488188668000@Atlassian.JIRA>
	<JIRA.12678969.1488188668000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678969.1488188668000.1682.1488188820245@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369462#comment-13369462 ] 

Jeff Mesnil commented on WFLY-8247:
-----------------------------------

The way how Artemis appends data to file was changed in Artemis, so SQL command in EAP's journal-sql.properties must be updated:

{code}
-append-to-file=UPDATE %s SET DATA = CONCAT(DATA, ?) WHERE ID=?
+append-to-file=SELECT DATA FROM %s WHERE ID=? FOR UPDATE
{code}

append-to-file.derby should be updated as well.

> Unable to send large message if JDBC-persistance-store is used
> --------------------------------------------------------------
>
>                 Key: WFLY-8247
>                 URL: https://issues.jboss.org/browse/WFLY-8247
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>         Environment: The issue was hit with Oracle 12c database
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> If producer sends large message to EAP with JDBC-persistance store, the following error arises on the server.
> {code}
> 11:49:34,248 ERROR [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ224016: Caught exception: ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=Invalid conversion requested]
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:458)
> 	at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.sendLarge(ServerSessionImpl.java:1189)
> 	at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:436)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:624)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373)
> 	at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356)
> 	at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621)
> 	at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277)
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:264)
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292)
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278)
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:962)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:435)
> 	at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:371)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) [xnio-nio-3.4.1.Final-redhat-1.jar:3.4.1.Final-redhat-1]
> Caused by: java.sql.SQLException: Invalid conversion requested
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:832)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getNUMBER(T4CVarcharAccessor.java:239)
> 	at oracle.jdbc.driver.T4CVarcharAccessor.getInt(T4CVarcharAccessor.java:527)
> 	at oracle.jdbc.driver.GeneratedStatement.getInt(GeneratedStatement.java:217)
> 	at oracle.jdbc.driver.GeneratedScrollableResultSet.getInt(GeneratedScrollableResultSet.java:573)
> 	at org.jboss.jca.adapters.jdbc.WrappedResultSet.getInt(WrappedResultSet.java:1490)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createFile(JDBCSequentialFileFactoryDriver.java:165)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.openFile(JDBCSequentialFileFactoryDriver.java:102)
> 	at org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFile.open(JDBCSequentialFile.java:98)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:391)
> 	at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:370)
> 	... 21 more
> Caused by: java.lang.NumberFormatException
> 	at java.math.BigDecimal.<init>(BigDecimal.java:494) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:383) [rt.jar:1.8.0_111]
> 	at java.math.BigDecimal.<init>(BigDecimal.java:806) [rt.jar:1.8.0_111]
> 	at oracle.jdbc.driver.T4CVarcharAccessor.StringToNUMBER(T4CVarcharAccessor.java:825)
> 	... 31 more
> {code}
> *Customer impact*: Clients are not able to send large messages. Sending/receiving large messages is common customer use case. This blocks RFE EAP7-591.
> There is no workaround. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 05:06:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Mon, 27 Feb 2017 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8248) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678974.1488189921000@Atlassian.JIRA>
References: <JIRA.12678974.1488189921000@Atlassian.JIRA>
	<JIRA.12678974.1488189921501@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678974.1488189921000.1777.1488189960488@Atlassian.JIRA>

Josef Cacek created WFLY-8248:
---------------------------------

             Summary: EJB deployments with Elytron SD collides in EJB3 SD service
                 Key: WFLY-8248
                 URL: https://issues.jboss.org/browse/WFLY-8248
             Project: WildFly
          Issue Type: Bug
          Components: EJB, Security
            Reporter: Josef Cacek
            Assignee: Jan Kalina
            Priority: Critical
         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear

Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107

But it fails if there are more such deployments, because it mean second service with the same name:
{code}
00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
	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  Mon Feb 27 06:10:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 06:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.2311.1488193801009@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan updated HAWKULARQE-41:
-------------------------------------
    Description: 
Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



  was:
Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template

Bug should be fixed https://bugzilla.redhat.com/show_bug.cgi?id=1370499



> Hawkular Agent for EAP7.1
> -------------------------
>
>                 Key: HAWKULARQE-41
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: mfoley user
>
> Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 06:10:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 06:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.2315.1488193801167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-41:
----------------------------------------

    Assignee: Hayk Hovsepyan  (was: mfoley user)


> Hawkular Agent for EAP7.1
> -------------------------
>
>                 Key: HAWKULARQE-41
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 07:06:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 27 Feb 2017 07:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7322) LDAP referrals does not work
 in Elytron ldap-realm
In-Reply-To: <JIRA.12655247.1476704313000@Atlassian.JIRA>
References: <JIRA.12655247.1476704313000@Atlassian.JIRA>
	<JIRA.12655247.1476704313000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12655247.1476704313000.2901.1488197160402@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved WFLY-7322.
------------------------------
    Resolution: Done


> LDAP referrals does not work in Elytron ldap-realm
> --------------------------------------------------
>
>                 Key: WFLY-7322
>                 URL: https://issues.jboss.org/browse/WFLY-7322
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all:
> * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object)
> * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals
> Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 07:08:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 27 Feb 2017 07:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8232) SecurityAuditingTestCase
 fails with Elytron profile in AS TS
In-Reply-To: <JIRA.12678756.1487937652000@Atlassian.JIRA>
References: <JIRA.12678756.1487937652000@Atlassian.JIRA>
	<JIRA.12678756.1487937652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678756.1487937652000.2933.1488197280573@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned WFLY-8232:
--------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> SecurityAuditingTestCase fails with Elytron profile in AS TS
> ------------------------------------------------------------
>
>                 Key: WFLY-8232
>                 URL: https://issues.jboss.org/browse/WFLY-8232
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Test Suite
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>
> The {{SecurityAuditingTestCase}} fails when executed with Elytron profile ({{-Delytron}}) in AS TS.
> {code}
> cd testsuite/integration/basic
> mvn clean test -Dtest=SecurityAuditingTestCase -Delytron
> ...
> Failed tests: 
>   SecurityAuditingTestCase.testSingleMethodAnnotationsUser1Template:181->AnnSBTest.testSingleMethodAnnotationsUser1Template:156->AnnSBTest.lambda$testSingleMethodAnnotationsUser1Template$1:169 EJBAccessException not expected
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 07:40:00 2017
From: issues at jboss.org (Petr Kremensky (JIRA))
Date: Mon, 27 Feb 2017 07:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2332) ReloadRedirectTestCase
	stuck on HP-UX
In-Reply-To: <JIRA.12679001.1488199106000@Atlassian.JIRA>
References: <JIRA.12679001.1488199106000@Atlassian.JIRA>
	<JIRA.12679001.1488199106000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679001.1488199106000.3120.1488199200402@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Kremensky moved JBEAP-9151 to WFCORE-2332:
-----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2332  (was: JBEAP-9151)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Test Suite
                           (was: Test Suite)
    Affects Version/s: 3.0.0.Beta4
                           (was: 7.1.0.DR12)


> ReloadRedirectTestCase stuck on HP-UX
> -------------------------------------
>
>                 Key: WFCORE-2332
>                 URL: https://issues.jboss.org/browse/WFCORE-2332
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 3.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: Petr Kremensky
>
> org.jboss.as.test.manualmode.management.cli.ReloadRedirectTestCase from Wildfly core manual mode module stuck on HP-UX
> {{destroy()}} is unable to kill the process waiting for the user input (accept certificate dialogue). We could either destroy the process forcibly by updating CliProcessWrapper:
> {code:java}
>     public void destroyProcess() {
>         cliProcess.destroy();
>     }
> {code}
> to 
> {code:java}
>     public void destroyProcess() {
>         cliProcess.destroyForcibly();
>     }
> {code}
> or add {{cliProc.ctrlCAndWaitForClose();}} into finally block just before destroying the process in test case.
> ReloadRedirectTestCase#testReloadwithRedirect()
> {code:java}
>     finally {
>         cliProc.ctrlCAndWaitForClose();
>         cliProc.destroyProcess();
>     }
> {code}
> see WFCORE-2216 for test log and thread dump 
> I'll send a PR for the second option.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 08:25:01 2017
From: issues at jboss.org (Ondrej Kotek (JIRA))
Date: Mon, 27 Feb 2017 08:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2333) Native management interface
 does not work with SSL/TLS based on Elytron SSL Context
In-Reply-To: <JIRA.12679012.1488201724000@Atlassian.JIRA>
References: <JIRA.12679012.1488201724000@Atlassian.JIRA>
	<JIRA.12679012.1488201724000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679012.1488201724000.3470.1488201901193@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Kotek moved JBEAP-9153 to WFCORE-2333:
---------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2333  (was: JBEAP-9153)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Security
                           (was: Security)
    Affects Version/s: 3.0.0.Beta2
                           (was: 7.1.0.DR12)


> Native management interface does not work with SSL/TLS based on Elytron SSL Context
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2333
>                 URL: https://issues.jboss.org/browse/WFCORE-2333
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 3.0.0.Beta2
>            Reporter: Ondrej Kotek
>            Priority: Blocker
>
> Following [1,2] to set management {{native-interface}} backed by SSL Context from Elytron, {{jboss-cli}} connection results in:
> {{Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9999}}
> Are there any configuration steps that needs to be performed for this configuration to work?
> [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security#WildFlyElytronSecurity-EnableOnewaySSL%2FTLSfortheManagementInterfacesUsingtheElytronSubsystem
> [2] 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  Mon Feb 27 08:32:00 2017
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Mon, 27 Feb 2017 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-35) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12676684.1487083678000@Atlassian.JIRA>
References: <JIRA.12676684.1487083678000@Atlassian.JIRA>
	<JIRA.12676684.1487083678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676684.1487083678000.3524.1488202320228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vojtech Prusa reassigned HAWKULARQE-35:
---------------------------------------

    Assignee: Vojtech Prusa  (was: mfoley user)


> 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: Vojtech Prusa
>            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  Mon Feb 27 08:33:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 27 Feb 2017 08:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2334) It is possible to set
 buffer pool buffer-size attribute to negative value
In-Reply-To: <JIRA.12679013.1488202327000@Atlassian.JIRA>
References: <JIRA.12679013.1488202327000@Atlassian.JIRA>
	<JIRA.12679013.1488202327108@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679013.1488202327000.3525.1488202380143@Atlassian.JIRA>

Dmitrii Tikhomirov created WFCORE-2334:
------------------------------------------

             Summary: It is possible to set buffer pool buffer-size attribute to negative value
                 Key: WFCORE-2334
                 URL: https://issues.jboss.org/browse/WFCORE-2334
             Project: WildFly Core
          Issue Type: Bug
          Components: IO
    Affects Versions: 3.0.0.Beta5
            Reporter: Dmitrii Tikhomirov
            Assignee: Dmitrii Tikhomirov


Currently, setting of negative value passes:
{code}
[standalone at localhost:9990 /] /subsystem=io/buffer-pool=foo:write-attribute(name=buffer-size, value=-20
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
{code}
although error in server log is thrown after reload:
{code}
2017-02-27 08:36:29,222 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "io"),
    ("buffer-pool" => "foo")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"org.wildfly.io.buffer-pool.foo" => "org.jboss.msc.service.StartException in service org.wildfly.io.buffer-pool.foo: Failed to start service
    Caused by: java.lang.IllegalArgumentException: XNIO000015: Parameter 'bufferSize' is out of range"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.buffer-pool.foo"]
}
{code}

There should be validation of this attribute.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 08:33:00 2017
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Mon, 27 Feb 2017 08:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-35) Manual Testcases - Create
	and Run
In-Reply-To: <JIRA.12676684.1487083678000@Atlassian.JIRA>
References: <JIRA.12676684.1487083678000@Atlassian.JIRA>
	<JIRA.12676684.1487083678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676684.1487083678000.3529.1488202380290@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369618#comment-13369618 ] 

Vojtech Prusa commented on HAWKULARQE-35:
-----------------------------------------

https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/workitem?id=JBossON4-10032

> 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: Vojtech Prusa
>            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  Mon Feb 27 08:48:00 2017
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Mon, 27 Feb 2017 08:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2335) It is possible to set
 buffer pool buffers-per-slice attribute to negative value
In-Reply-To: <JIRA.12679019.1488203242000@Atlassian.JIRA>
References: <JIRA.12679019.1488203242000@Atlassian.JIRA>
	<JIRA.12679019.1488203242978@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679019.1488203242000.3675.1488203280282@Atlassian.JIRA>

Dmitrii Tikhomirov created WFCORE-2335:
------------------------------------------

             Summary: It is possible to set buffer pool buffers-per-slice attribute to negative value
                 Key: WFCORE-2335
                 URL: https://issues.jboss.org/browse/WFCORE-2335
             Project: WildFly Core
          Issue Type: Bug
          Components: IO
            Reporter: Dmitrii Tikhomirov
            Assignee: Dmitrii Tikhomirov


Currently, setting of negative value passes:
{code}
[standalone at localhost:9990 /] /subsystem=io/buffer-pool=foo:write-attribute(name=buffers-per-slice, value=-20
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
{code}
although error in server log is thrown after reload, it contains only error message about 'bufferSize' when I was setting buffers-per-slice attribute:
{code}
2017-02-27 08:46:13,117 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "io"),
    ("buffer-pool" => "foo")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"org.wildfly.io.buffer-pool.foo" => "org.jboss.msc.service.StartException in service org.wildfly.io.buffer-pool.foo: Failed to start service
    Caused by: java.lang.IllegalArgumentException: XNIO000015: Parameter 'bufferSize' is out of range"},
    "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.buffer-pool.foo"]
}
{code}

There should be validation of this attribute.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:11:02 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:11:02 -0500 (EST)
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: <JIRA.12673917.1485869843000@Atlassian.JIRA>
References: <JIRA.12673917.1485869843000@Atlassian.JIRA>
	<JIRA.12673917.1485869843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673917.1485869843000.4115.1488204662406@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-9:
---------------------------------------

    Assignee: Hayk Hovsepyan  (was: Filip Brychta)


> [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: Hayk Hovsepyan
>              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  Mon Feb 27 09:12:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-25) Upstream work on APM
In-Reply-To: <JIRA.12674016.1485888089000@Atlassian.JIRA>
References: <JIRA.12674016.1485888089000@Atlassian.JIRA>
	<JIRA.12674016.1485888089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674016.1485888089000.4156.1488204721720@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-25:
----------------------------------------

    Assignee: Hayk Hovsepyan  (was: Jeeva Kandasamy)


> Upstream work on APM
> --------------------
>
>                 Key: HAWKULARQE-25
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-25
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Top level task for Upstream work.
> All work goes as sub-tasks here.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:13:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment
In-Reply-To: <JIRA.12677335.1487269804000@Atlassian.JIRA>
References: <JIRA.12677335.1487269804000@Atlassian.JIRA>
	<JIRA.12677335.1487269804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677335.1487269804000.4164.1488204780558@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-37:
----------------------------------------

    Assignee: Hayk Hovsepyan  (was: Prachi Yadav)


> Server Group Deployment
> -----------------------
>
>                 Key: HAWKULARQE-37
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-37
>             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 Feb 27 09:13:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated
 on failed operations
In-Reply-To: <JIRA.12677830.1487600438000@Atlassian.JIRA>
References: <JIRA.12677830.1487600438000@Atlassian.JIRA>
	<JIRA.12677830.1487600438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677830.1487600438000.4173.1488204781309@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-44:
----------------------------------------

    Assignee: Hayk Hovsepyan  (was: Prachi Yadav)


> 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: Hayk Hovsepyan
>
> 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  Mon Feb 27 09:14:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:14: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: <JIRA.12677885.1487602065000@Atlassian.JIRA>
References: <JIRA.12677885.1487602065000@Atlassian.JIRA>
	<JIRA.12677885.1487602065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677885.1487602065000.4180.1488204840426@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-45:
----------------------------------------

    Assignee: Sunil kondkar  (was: mfoley user)


> 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 Feb 27 09:14:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:14: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: <JIRA.12677885.1487602065000@Atlassian.JIRA>
References: <JIRA.12677885.1487602065000@Atlassian.JIRA>
	<JIRA.12677885.1487602065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677885.1487602065000.4185.1488204840564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-45:
----------------------------------------

    Assignee: Hayk Hovsepyan  (was: Sunil kondkar)


> 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: Hayk Hovsepyan
>
> 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 Feb 27 09:16:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-24) HOSA --- Hawkular Agent
	for Openshift
In-Reply-To: <JIRA.12674015.1485888026000@Atlassian.JIRA>
References: <JIRA.12674015.1485888026000@Atlassian.JIRA>
	<JIRA.12674015.1485888026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674015.1485888026000.4217.1488204960998@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-24:
----------------------------------------

    Assignee: viet nguyen  (was: mfoley user)


> 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  Mon Feb 27 09:17:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-25) Upstream work on APM
In-Reply-To: <JIRA.12674016.1485888089000@Atlassian.JIRA>
References: <JIRA.12674016.1485888089000@Atlassian.JIRA>
	<JIRA.12674016.1485888089000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674016.1485888089000.4225.1488205020500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-25:
----------------------------------------

    Assignee: Jeeva Kandasamy  (was: Hayk Hovsepyan)


> Upstream work on APM
> --------------------
>
>                 Key: HAWKULARQE-25
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-25
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Jeeva Kandasamy
>
> Top level task for Upstream work.
> All work goes as sub-tasks here.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:17:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-37) Server Group Deployment
In-Reply-To: <JIRA.12677335.1487269804000@Atlassian.JIRA>
References: <JIRA.12677335.1487269804000@Atlassian.JIRA>
	<JIRA.12677335.1487269804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677335.1487269804000.4245.1488205021040@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-37:
----------------------------------------

    Assignee: Prachi Yadav  (was: Hayk Hovsepyan)


> 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 Feb 27 09:18:00 2017
From: issues at jboss.org (viet nguyen (JIRA))
Date: Mon, 27 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-26) Build an Openshift Origin
 cluster on public OS1
In-Reply-To: <JIRA.12674020.1485891892000@Atlassian.JIRA>
References: <JIRA.12674020.1485891892000@Atlassian.JIRA>
	<JIRA.12674020.1485891892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674020.1485891892000.4257.1488205080780@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369656#comment-13369656 ] 

viet nguyen commented on HAWKULARQE-26:
---------------------------------------

Installed a single-node cluster
master:  http://master.cloud1.hawkular.org


> Build an Openshift Origin cluster on public OS1
> -----------------------------------------------
>
>                 Key: HAWKULARQE-26
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-26
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: viet nguyen
>            Assignee: viet nguyen
>
> Build a small cluster of OpenShift Origin on public OS1 for CI and manual testing



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:18:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2336) Remove
	ModelController.createClient
In-Reply-To: <JIRA.12679023.1488205056000@Atlassian.JIRA>
References: <JIRA.12679023.1488205056000@Atlassian.JIRA>
	<JIRA.12679023.1488205056885@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679023.1488205056000.4259.1488205080840@Atlassian.JIRA>

Brian Stansberry created WFCORE-2336:
----------------------------------------

             Summary: Remove ModelController.createClient
                 Key: WFCORE-2336
                 URL: https://issues.jboss.org/browse/WFCORE-2336
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
             Fix For: 4.0.0.Alpha1


Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:18:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-44) Verify events generated
 on failed operations
In-Reply-To: <JIRA.12677830.1487600438000@Atlassian.JIRA>
References: <JIRA.12677830.1487600438000@Atlassian.JIRA>
	<JIRA.12677830.1487600438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677830.1487600438000.4255.1488205080714@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-44:
----------------------------------------

    Assignee: Prachi Yadav  (was: Hayk Hovsepyan)


> 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  Mon Feb 27 09:18:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:18: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: <JIRA.12677885.1487602065000@Atlassian.JIRA>
References: <JIRA.12677885.1487602065000@Atlassian.JIRA>
	<JIRA.12677885.1487602065000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677885.1487602065000.4264.1488205080959@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-45:
----------------------------------------

    Assignee: Sunil kondkar  (was: Hayk Hovsepyan)


> 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 Feb 27 09:19:00 2017
From: issues at jboss.org (viet nguyen (JIRA))
Date: Mon, 27 Feb 2017 09:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-26) Build an Openshift Origin
 cluster on public OS1
In-Reply-To: <JIRA.12674020.1485891892000@Atlassian.JIRA>
References: <JIRA.12674020.1485891892000@Atlassian.JIRA>
	<JIRA.12674020.1485891892000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674020.1485891892000.4269.1488205140270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

viet nguyen resolved HAWKULARQE-26.
-----------------------------------
    Resolution: Done


> Build an Openshift Origin cluster on public OS1
> -----------------------------------------------
>
>                 Key: HAWKULARQE-26
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-26
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: viet nguyen
>            Assignee: viet nguyen
>
> Build a small cluster of OpenShift Origin on public OS1 for CI and manual testing



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:20:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:20:00 -0500 (EST)
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: <JIRA.12673917.1485869843000@Atlassian.JIRA>
References: <JIRA.12673917.1485869843000@Atlassian.JIRA>
	<JIRA.12673917.1485869843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673917.1485869843000.4273.1488205200278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan reassigned HAWKULARQE-9:
---------------------------------------

    Assignee: Filip Brychta  (was: Hayk Hovsepyan)


> [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  Mon Feb 27 09:22:01 2017
From: issues at jboss.org (viet nguyen (JIRA))
Date: Mon, 27 Feb 2017 09:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-47) Perform and document a
 small load test run
In-Reply-To: <JIRA.12679024.1488205308000@Atlassian.JIRA>
References: <JIRA.12679024.1488205308000@Atlassian.JIRA>
	<JIRA.12679024.1488205308304@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679024.1488205308000.4310.1488205321815@Atlassian.JIRA>

viet nguyen created HAWKULARQE-47:
-------------------------------------

             Summary: 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: mfoley user


- 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 Feb 27 09:23:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 09:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.4331.1488205380919@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-8238:
---------------------------------

    Assignee: Martin Choma  (was: Jeff Mesnil)


> 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: Martin Choma
>
> 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  Mon Feb 27 09:33:01 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Mon, 27 Feb 2017 09:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-880) Unable to set IPv6 address in
 Elytron authentication context match-host rule
In-Reply-To: <JIRA.12671435.1484584402000@Atlassian.JIRA>
References: <JIRA.12671435.1484584402000@Atlassian.JIRA>
	<JIRA.12671435.1484584402000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671435.1484584402000.4621.1488205981188@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369674#comment-13369674 ] 

Tomas Hofman commented on ELY-880:
----------------------------------

PR is up. David Lloyd expressed an opinion that more advanced IP address matching should be performed by a separate AddressMatcher rather than the current HostMatcher, so I updated the PR to perform just equality check.

> Unable to set IPv6 address in Elytron authentication context match-host rule
> ----------------------------------------------------------------------------
>
>                 Key: ELY-880
>                 URL: https://issues.jboss.org/browse/ELY-880
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.1.0.Beta18
>            Reporter: Martin Choma
>            Assignee: Tomas Hofman
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Setting IPv6 address in wildfly-config.xml cause validation error.
> {code:xml|title=wildfly-config.xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <authentication-client xmlns="urn:elytron:1.0">
>     <authentication-configurations>
>         <configuration name="set-host-to-localhost">
>             <set-host name="localhost"/>
>         </configuration>
>     </authentication-configurations>
>     <authentication-rules>
>         <rule use-configuration="set-host-to-localhost">
>             <match-host name="::1"/>
>         </rule>
>     </authentication-rules>
> </authentication-client> 
> {code}
> {code:title=server.log}
> java.lang.IllegalArgumentException: ELY01029: Invalid host specification "::1"
> 	at org.wildfly.security.auth.client.MatchHostRule.<init>(MatchHostRule.java:39)
> 	at org.wildfly.security.auth.client.MatchRule.matchHost(MatchRule.java:411)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAbstractMatchRuleType(ElytronXmlParser.java:701)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationRuleType(ElytronXmlParser.java:467)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseRulesType(ElytronXmlParser.java:484)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:241)
> 	at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:169)
> 	at org.wildfly.security.auth.client.XmlConfigurationTest.testMatcHostRuleConfiguration(XmlConfigurationTest.java:175)
> 	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:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> It is because of elytron validation [1]. However don't know if just allowing ":" in regexp is valid solution.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/7debbcabc7c20be56331118e84de5ccf09bec36d/src/main/java/org/wildfly/security/auth/client/MatchHostRule.java#L32



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:36:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 27 Feb 2017 09:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2337) Removal of overlay in a
 server group fails inside a composite
In-Reply-To: <JIRA.12679032.1488206106000@Atlassian.JIRA>
References: <JIRA.12679032.1488206106000@Atlassian.JIRA>
	<JIRA.12679032.1488206106981@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679032.1488206106000.4659.1488206160205@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2337:
--------------------------------------------

             Summary: 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: Brian Stansberry


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  Mon Feb 27 09:39:00 2017
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 27 Feb 2017 09:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2337) Removal of overlay in a
 server group fails inside a composite
In-Reply-To: <JIRA.12679032.1488206107000@Atlassian.JIRA>
References: <JIRA.12679032.1488206107000@Atlassian.JIRA>
	<JIRA.12679032.1488206107000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679032.1488206107000.4699.1488206340828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFCORE-2337:
-----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Brian Stansberry)


> 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
>
> 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  Mon Feb 27 09:44:00 2017
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 27 Feb 2017 09:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.4776.1488206640836@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369682#comment-13369682 ] 

Farah Juma commented on WFLY-8241:
----------------------------------

This was fixed in WFLY-8171:

https://github.com/wildfly/wildfly/pull/9681



> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Mon Feb 27 09:52:01 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Mon, 27 Feb 2017 09:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-31) CFME Tests: Adjust
 Datasource automation tests to 4.5 release.
In-Reply-To: <JIRA.12675545.1486563783000@Atlassian.JIRA>
References: <JIRA.12675545.1486563783000@Atlassian.JIRA>
	<JIRA.12675545.1486563783000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675545.1486563783000.4905.1488207121197@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369691#comment-13369691 ] 

Hayk Hovsepyan commented on HAWKULARQE-31:
------------------------------------------

Blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1427141

> 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 Feb 27 09:56:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 27 Feb 2017 09:56:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8157) Synchronize XSD and DMR
 description of credential-store attributes
In-Reply-To: <JIRA.12677496.1487326382000@Atlassian.JIRA>
References: <JIRA.12677496.1487326382000@Atlassian.JIRA>
	<JIRA.12677496.1487326382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677496.1487326382000.5029.1488207361295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8157:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Synchronize XSD and DMR description of credential-store attributes
> ------------------------------------------------------------------
>
>                 Key: WFLY-8157
>                 URL: https://issues.jboss.org/browse/WFLY-8157
>             Project: WildFly
>          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}
>         <xs:attribute name="type" type="xs:string" use="optional">
>             <xs:annotation>
>                 <xs:documentation>
>                     The credential store type, e.g. KeyStorePasswordStore.
>                 </xs:documentation>
>             </xs:annotation>
>         </xs:attribute>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 09:59:01 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 27 Feb 2017 09:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2338) Error applying patch
	through CLI
In-Reply-To: <JIRA.12679034.1488207517000@Atlassian.JIRA>
References: <JIRA.12679034.1488207517000@Atlassian.JIRA>
	<JIRA.12679034.1488207517816@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679034.1488207517000.5083.1488207541056@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-2338:
--------------------------------------------

             Summary: Error applying patch through CLI
                 Key: WFCORE-2338
                 URL: https://issues.jboss.org/browse/WFCORE-2338
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 10:02:00 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 27 Feb 2017 10: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: <JIRA.12679036.1488207678000@Atlassian.JIRA>
References: <JIRA.12679036.1488207678000@Atlassian.JIRA>
	<JIRA.12679036.1488207678041@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679036.1488207678000.5163.1488207720265@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-48:
---------------------------------------

             Summary: 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


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 Feb 27 10:03:01 2017
From: issues at jboss.org (Filip Brychta (JIRA))
Date: Mon, 27 Feb 2017 10:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-49) Prepare,
 run and atomate installation and upgrade testcases for h-metrics
In-Reply-To: <JIRA.12679037.1488207737000@Atlassian.JIRA>
References: <JIRA.12679037.1488207737000@Atlassian.JIRA>
	<JIRA.12679037.1488207737981@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679037.1488207737000.5180.1488207781032@Atlassian.JIRA>

Filip Brychta created HAWKULARQE-49:
---------------------------------------

             Summary: Prepare, run and atomate installation and upgrade testcases for h-metrics
                 Key: HAWKULARQE-49
                 URL: https://issues.jboss.org/browse/HAWKULARQE-49
             Project: Hawkular QE
          Issue Type: Task
            Reporter: Filip Brychta
            Assignee: mfoley user


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-metrics 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 Feb 27 10:22:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 27 Feb 2017 10:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8068) Credential-store attribute
 relative-to doesn't reference path as required
In-Reply-To: <JIRA.12675844.1486669361000@Atlassian.JIRA>
References: <JIRA.12675844.1486669361000@Atlassian.JIRA>
	<JIRA.12675844.1486669361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12675844.1486669361000.5387.1488208920503@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8068:
-----------------------------------

    Assignee: Ilia Vassilev


> Credential-store attribute relative-to doesn't reference path as required
> -------------------------------------------------------------------------
>
>                 Key: WFLY-8068
>                 URL: https://issues.jboss.org/browse/WFLY-8068
>             Project: WildFly
>          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  Mon Feb 27 10:23:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 27 Feb 2017 10:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7970) Elytron keystore type default
	value
In-Reply-To: <JIRA.12673026.1485355874000@Atlassian.JIRA>
References: <JIRA.12673026.1485355874000@Atlassian.JIRA>
	<JIRA.12673026.1485355874000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673026.1485355874000.5397.1488208980711@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7970:
-----------------------------------

    Assignee: Ilia Vassilev


> Elytron keystore type default value
> -----------------------------------
>
>                 Key: WFLY-7970
>                 URL: https://issues.jboss.org/browse/WFLY-7970
>             Project: WildFly
>          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  Mon Feb 27 10:38:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 27 Feb 2017 10:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7956) Coverity static analysis:
 Performace optimalization in map iterating
In-Reply-To: <JIRA.12672890.1485278153000@Atlassian.JIRA>
References: <JIRA.12672890.1485278153000@Atlassian.JIRA>
	<JIRA.12672890.1485278153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672890.1485278153000.5522.1488209880380@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-7956:
-----------------------------------

    Assignee: Ilia Vassilev


> Coverity static analysis: Performace optimalization in map iterating
> --------------------------------------------------------------------
>
>                 Key: WFLY-7956
>                 URL: https://issues.jboss.org/browse/WFLY-7956
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Minor
>
> Coverity static analysis found iterating over map can be enhanced
> https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=8486751&defectInstanceId=2122705&mergedDefectId=1389593
> Instead of Map.keySet() + Map.get() combo use just Map.entrySet().
>  
> {code:java|title=ElytronHttpExchange#getRequestParameters}
> for (String name : queryParameters.keySet()) {
>     List<String> values = new ArrayList<>(queryParameters.get(name));
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 10:41:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 27 Feb 2017 10:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8249) Upgrade Narayana to
	5.5.3.Final
In-Reply-To: <JIRA.12679048.1488210006000@Atlassian.JIRA>
References: <JIRA.12679048.1488210006000@Atlassian.JIRA>
	<JIRA.12679048.1488210006852@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679048.1488210006000.5564.1488210060234@Atlassian.JIRA>

Tom Jenkinson created WFLY-8249:
-----------------------------------

             Summary: Upgrade Narayana to 5.5.3.Final
                 Key: WFLY-8249
                 URL: https://issues.jboss.org/browse/WFLY-8249
             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  Mon Feb 27 10:46:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 27 Feb 2017 10:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8250) Ensure all subsystem
 resources that depend on the core services also record a capability
 dependency.
In-Reply-To: <JIRA.12679051.1488210315000@Atlassian.JIRA>
References: <JIRA.12679051.1488210315000@Atlassian.JIRA>
	<JIRA.12679051.1488210315360@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679051.1488210315000.5609.1488210360311@Atlassian.JIRA>

Darran Lofthouse created WFLY-8250:
--------------------------------------

             Summary: Ensure all 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.Alpha1


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 Feb 27 10:48:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 27 Feb 2017 10:48:00 -0500 (EST)
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: <JIRA.12679051.1488210315000@Atlassian.JIRA>
References: <JIRA.12679051.1488210315000@Atlassian.JIRA>
	<JIRA.12679051.1488210315000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679051.1488210315000.5640.1488210480301@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-8250:
-----------------------------------
    Summary: Ensure all Elytron subsystem resources that depend on the core services also record a capability dependency.  (was: Ensure all subsystem resources that depend on the core services also record a capability dependency.)


> 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.Alpha1
>
>
> 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 Feb 27 10:54:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 27 Feb 2017 10:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8249) Upgrade Narayana to
	5.5.3.Final
In-Reply-To: <JIRA.12679048.1488210007000@Atlassian.JIRA>
References: <JIRA.12679048.1488210007000@Atlassian.JIRA>
	<JIRA.12679048.1488210007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679048.1488210007000.5694.1488210840648@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-8249:
--------------------------------
    Description: 
https://issues.jboss.org/projects/JBTM/versions/12333775
https://github.com/jbosstm/narayana/commits/5.5.3.Final


> Upgrade Narayana to 5.5.3.Final
> -------------------------------
>
>                 Key: WFLY-8249
>                 URL: https://issues.jboss.org/browse/WFLY-8249
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> https://issues.jboss.org/projects/JBTM/versions/12333775
> https://github.com/jbosstm/narayana/commits/5.5.3.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 10:55:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 27 Feb 2017 10:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8251) Upgrade Narayana to
	5.5.3.Final
In-Reply-To: <JIRA.12679053.1488210861000@Atlassian.JIRA>
References: <JIRA.12679053.1488210861000@Atlassian.JIRA>
	<JIRA.12679053.1488210861048@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679053.1488210861000.5716.1488210900482@Atlassian.JIRA>

Tom Jenkinson created WFLY-8251:
-----------------------------------

             Summary: Upgrade Narayana to 5.5.3.Final
                 Key: WFLY-8251
                 URL: https://issues.jboss.org/browse/WFLY-8251
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson


https://issues.jboss.org/projects/JBTM/versions/12333775
https://github.com/jbosstm/narayana/commits/5.5.3.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 10:56:00 2017
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 27 Feb 2017 10:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8249) Upgrade Narayana to
	5.5.3.Final
In-Reply-To: <JIRA.12679048.1488210007000@Atlassian.JIRA>
References: <JIRA.12679048.1488210007000@Atlassian.JIRA>
	<JIRA.12679048.1488210007000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679048.1488210007000.5741.1488210960275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-8249:
--------------------------------
    Priority: Blocker  (was: Major)


> Upgrade Narayana to 5.5.3.Final
> -------------------------------
>
>                 Key: WFLY-8249
>                 URL: https://issues.jboss.org/browse/WFLY-8249
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>
> https://issues.jboss.org/projects/JBTM/versions/12333775
> https://github.com/jbosstm/narayana/commits/5.5.3.Final



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 11:16:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 27 Feb 2017 11:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.6008.1488212160529@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil reassigned WFLY-8238:
---------------------------------

    Assignee: Tomas Hofman  (was: Martin Choma)


> 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  Mon Feb 27 11:35:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 27 Feb 2017 11:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7868) Embedded server,
 elytron filesystem-realm creation requires reload
In-Reply-To: <JIRA.12670148.1484060965000@Atlassian.JIRA>
References: <JIRA.12670148.1484060965000@Atlassian.JIRA>
	<JIRA.12670148.1484060965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12670148.1484060965000.6213.1488213300667@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369785#comment-13369785 ] 

Ken Wills commented on WFLY-7868:
---------------------------------

We don't have standalone-elytron.xml in either core or full anymore, and elytron is enabled in the stock standalone.xml, so this doesn't appear to be an issue any longer.

> Embedded server, elytron filesystem-realm creation requires reload
> ------------------------------------------------------------------
>
>                 Key: WFLY-7868
>                 URL: https://issues.jboss.org/browse/WFLY-7868
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ken Wills
>
> In embedded server, when elytron filesystem realm is created command response is not marked with {{reload-required}}. However subsequent attempt to use this filesystem realm fails.
> When reload is called between this 2 commands it is OK. 
> When trying on standalone server it is OK.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 11:36:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 27 Feb 2017 11:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7868) Embedded server,
 elytron filesystem-realm creation requires reload
In-Reply-To: <JIRA.12670148.1484060965000@Atlassian.JIRA>
References: <JIRA.12670148.1484060965000@Atlassian.JIRA>
	<JIRA.12670148.1484060965000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12670148.1484060965000.6234.1488213360413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills resolved WFLY-7868.
-----------------------------
    Resolution: Cannot Reproduce Bug


> Embedded server, elytron filesystem-realm creation requires reload
> ------------------------------------------------------------------
>
>                 Key: WFLY-7868
>                 URL: https://issues.jboss.org/browse/WFLY-7868
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Martin Choma
>            Assignee: Ken Wills
>
> In embedded server, when elytron filesystem realm is created command response is not marked with {{reload-required}}. However subsequent attempt to use this filesystem realm fails.
> When reload is called between this 2 commands it is OK. 
> When trying on standalone server it is OK.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 11:40:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 27 Feb 2017 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2090) CLIEmbedServerTestCase hang
In-Reply-To: <JIRA.12665797.1481052985000@Atlassian.JIRA>
References: <JIRA.12665797.1481052985000@Atlassian.JIRA>
	<JIRA.12665797.1481052985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665797.1481052985000.6284.1488213600309@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369789#comment-13369789 ] 

Ken Wills commented on WFCORE-2090:
-----------------------------------

This hasn't occurred since the single even reported. Closing this for now, will re-open if it resurfaces.

> CLIEmbedServerTestCase hang
> ---------------------------
>
>                 Key: WFCORE-2090
>                 URL: https://issues.jboss.org/browse/WFCORE-2090
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It appears that CLIEmbedTestCase hung on 2016-12-06 at approx 643am EST. (Edit, see stack below. (A previous version of this suggested that the surefire logs indicated completion, but that was for the hostcontroller version of these tests.)
> A subsequent run, or running locally didn't cause the issue to occur.
> I'm leaving this hear as a placeholder for if / when this occurs again.
> Stack:
> [07:30:20][org.wildfly.core:wildfly-core-testsuite-manualmode] The build Pull Request::Pull request - Linux #5015 {buildId=36570} has been running for more than 75 minutes. Terminating...
> [07:30:25][org.wildfly.core:wildfly-core-testsuite-manualmode] Dumping threads before termination:
> [07:30:25][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 13627, PPID: 24231, Command line: /usr/java/jdk1.8.0_74/bin/java -Dagent.home.dir=/opt/buildAgent -Dagent.name=build03-el7 -Dagent.ownPort=9090 -Dagent.work.dir=/store/work/tc-work -Dbuild.number=5015 -Dbuild.vcs.number=0578e793a94cca04241a005583d43ad2b95a08f0 -Dbuild.vcs.number.1=0578e793a94cca04241a005583d43ad2b95a08f0 -Dbuild.vcs.number.WildFlyCore_WildFlyPullRequest=0578e793a94cca04241a005583d43ad2b95a08f0 -Dclassworlds.conf=/store/work/temp/buildTmp/teamcity.m2.conf -Dcom.jetbrains.maven.watcher.report.file=/store/work/temp/buildTmp/maven-build-info.xml -Djava.io.tmpdir=/store/work/temp/buildTmp -Dmaven.home=/opt/buildAgent/tools/maven32 -Dmaven.multiModuleProjectDirectory=/store/work/tc-work/4c983eca15c0017f -Dmaven.repo.local=/store/repository -Dteamcity.agent.cpuBenchmark=470 -Dteamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2 -Dteamcity.agent.dotnet.build_id=36570 -Dteamcity.auth.password=x8SPJnse6VqpvVQaNPLYBxuWRKejITxg -Dteamcity.auth.userId=TeamCityBuildId=36570 -Dteamcity.build.changedFiles.file=/store/work/temp/buildTmp/changedFiles1871277749042159253.txt -Dteamcity.build.checkoutDir=/store/work/tc-work/4c983eca15c0017f -Dteamcity.build.id=36570 -Dteamcity.build.properties.file=/store/work/temp/buildTmp/teamcity.build2954197549655995262.properties -Dteamcity.build.tempDir=/store/work/temp/buildTmp -Dteamcity.build.workingDir=/store/work/tc-work/4c983eca15c0017f -Dteamcity.buildConfName=Pull request - Linux -Dteamcity.buildType.id=WildFlyCore_PullRequest -Dteamcity.configuration.properties.file=/store/work/temp/buildTmp/teamcity.config7895286397916148834.properties -Dteamcity.maven.userSettings.path=/store/work/temp/buildTmp/maven_settings_6089771320309764773.xml -Dteamcity.maven.watcher.home=/opt/buildAgent/plugins/mavenPlugin/maven-watcher -Dteamcity.projectName=Pull Request -Dteamcity.runner.properties.file=/store/work/temp/buildTmp/teamcity.runner4428557639185750647.properties -Dteamcity.tests.recentlyFailedTests.file=/store/work/temp/buildTmp/testsToRunFirst3153555266480301879.txt -Dteamcity.version=9.1.7 (build 37573) -Xms512M -Xmx768M -classpath /opt/buildAgent/tools/maven32/boot/plexus-classworlds-2.5.2.jar: org.codehaus.plexus.classworlds.launcher.Launcher -f /store/work/tc-work/4c983eca15c0017f/pom.xml -B clean install -s /store/work/temp/buildTmp/maven_settings_6089771320309764773.xml -fae -U -DallTests -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dipv6 -Dorg.jboss.model.test.maven.repository.urls=http://repository.ci.wildfly.org/content/groups/public/
> [07:30:26]
> [org.wildfly.core:wildfly-core-testsuite-manualmode] 2016-12-06 06:30:27
> Full thread dump Java HotSpot(TM) Server VM (25.74-b02 mixed mode):
> "Attach Listener" #882 daemon prio=9 os_prio=0 tid=0xb4304800 nid=0x7843 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Thread-271" #880 prio=5 os_prio=0 tid=0xab874c00 nid=0x763d runnable [0xaedaa000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:255)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> 	- locked <0xd7251740> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> 	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> 	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> 	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> 	- locked <0xd7256708> (a java.io.InputStreamReader)
> 	at java.io.InputStreamReader.read(InputStreamReader.java:184)
> 	at java.io.BufferedReader.fill(BufferedReader.java:161)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:324)
> 	- locked <0xd7256708> (a java.io.InputStreamReader)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:389)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66)
> "Thread-270" #879 prio=5 os_prio=0 tid=0xab107c00 nid=0x763c runnable [0xaed59000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:255)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> 	- locked <0xd724f6a0> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> 	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> 	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> 	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> 	- locked <0xd7253b38> (a java.io.InputStreamReader)
> 	at java.io.InputStreamReader.read(InputStreamReader.java:184)
> 	at java.io.BufferedReader.fill(BufferedReader.java:161)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:324)
> 	- locked <0xd7253b38> (a java.io.InputStreamReader)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:389)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66)
> "ThreadedStreamConsumer" #878 prio=5 os_prio=0 tid=0xad9ed400 nid=0x763a waiting on condition [0xaeefe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xd72411b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:68)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-86-thread-1" #805 prio=5 os_prio=0 tid=0xab107400 nid=0x66dc in Object.wait() [0xaedfb000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396)
> 	- locked <0xd724d440> (a java.lang.UNIXProcess)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:202)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:141)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:471)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:380)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$300(ForkStarter.java:88)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:315)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:306)
> 	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)
> "resolver-5" #24 daemon prio=5 os_prio=0 tid=0xb0e25400 nid=0x355d waiting on condition [0xaee4c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-4" #23 daemon prio=5 os_prio=0 tid=0xb3b8b400 nid=0x355c waiting on condition [0xb0290000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-3" #22 daemon prio=5 os_prio=0 tid=0xb3b8a400 nid=0x355b waiting on condition [0xb13b2000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-2" #21 daemon prio=5 os_prio=0 tid=0xb3b8a000 nid=0x355a waiting on condition [0xb168f000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-1" #20 daemon prio=5 os_prio=0 tid=0xb0ebc000 nid=0x3559 waiting on condition [0xb16e0000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "process reaper" #10 daemon prio=10 os_prio=0 tid=0xb11b1400 nid=0x354e runnable [0xb16f9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.UNIXProcess.waitForProcessExit(Native Method)
> 	at java.lang.UNIXProcess.lambda$initStreams$3(UNIXProcess.java:290)
> 	at java.lang.UNIXProcess$$Lambda$7/11278477.run(Unknown Source)
> 	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)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0xb44aa800 nid=0x3548 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xb44a7000 nid=0x3547 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xb44a5c00 nid=0x3546 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xb44a3c00 nid=0x3545 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xb44a2400 nid=0x3544 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0xb4488000 nid=0x3543 in Object.wait() [0xb687d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xb8759ca0> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xb4485400 nid=0x3542 in Object.wait() [0xb6b7d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> 	- locked <0xb8761898> (a java.lang.ref.Reference$Lock)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0xf6508800 nid=0x353c waiting on condition [0xf672a000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xbc759d20> (a java.util.concurrent.FutureTask)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:327)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:178)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:990)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:824)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:722)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 	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.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)
> "VM Thread" os_prio=0 tid=0xb4480c00 nid=0x3541 runnable 
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6512000 nid=0x353d runnable 
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6513400 nid=0x353e runnable 
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6514c00 nid=0x353f runnable 
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6516000 nid=0x3540 runnable 
> "VM Periodic Task Thread" os_prio=0 tid=0xb44bd800 nid=0x3549 waiting on condition 
> JNI global references: 289
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 30267, PPID: 13627, Command line: /bin/sh -c cd /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode && /usr/java/jdk1.8.0_74/jre/bin/java -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/wildfly-core -jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefirebooter8497614206686950307.jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire7659716555864739391tmp /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire_1307355743037353978607tmp
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] Failed to locate jps tool. No thread dump information is available
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 30270, PPID: 30267, Command line: /usr/java/jdk1.8.0_74/jre/bin/java -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/wildfly-core -jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefirebooter8497614206686950307.jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire7659716555864739391tmp /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire_1307355743037353978607tmp
> [07:30:26]
> [org.wildfly.core:wildfly-core-testsuite-manualmode] 2016-12-06 06:30:27
> Full thread dump Java HotSpot(TM) Server VM (25.74-b02 mixed mode):
> "Attach Listener" #435 daemon prio=9 os_prio=0 tid=0xc4d5dc00 nid=0x785a waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "ServerService Thread Pool -- 16" #434 prio=5 os_prio=0 tid=0xc0c51800 nid=0x77f7 waiting on condition [0xbfcf6000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerService Thread Pool -- 15" #433 prio=5 os_prio=0 tid=0xc0c33c00 nid=0x77f6 waiting on condition [0xc1c5b000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerService Thread Pool -- 13" #431 prio=5 os_prio=0 tid=0xc0c00c00 nid=0x77f4 waiting on condition [0xc1afe000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "Timer-4" #430 prio=5 os_prio=0 tid=0xc0ef4000 nid=0x77f3 in Object.wait() [0xc035c000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xdcbaebc0> (a java.util.TaskQueue)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.util.TimerThread.mainLoop(Timer.java:526)
> 	- locked <0xdcbaebc0> (a java.util.TaskQueue)
> 	at java.util.TimerThread.run(Timer.java:505)
> "management Accept" #429 prio=5 os_prio=0 tid=0xc46c0400 nid=0x77f2 runnable [0xc1cac000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba7270> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba7260> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba7168> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-2" #428 prio=5 os_prio=0 tid=0xc44b6c00 nid=0x77f1 runnable [0xbf93e000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba5808> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba57f8> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba5700> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-1" #427 prio=5 os_prio=0 tid=0xc0c32000 nid=0x77f0 runnable [0xc03ad000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba3da0> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba3d90> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba3c98> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "MSC service thread 14-5" #409 prio=5 os_prio=0 tid=0xc0efc800 nid=0x77e7 waiting on condition [0xc0bad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "ServerService Thread Pool -- 4" #418 prio=5 os_prio=0 tid=0xc0ef3000 nid=0x77e6 waiting on condition [0xc09ba000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerDeploymentRepository-temp-threads - 1" #413 daemon prio=5 os_prio=0 tid=0xbe74b800 nid=0x77e1 waiting on condition [0xc29ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3e88> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "MSC service thread 14-8" #412 prio=5 os_prio=0 tid=0xbe738400 nid=0x77e0 waiting on condition [0xc05ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-7" #411 prio=5 os_prio=0 tid=0xc0efa400 nid=0x77df waiting on condition [0xc10ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-6" #410 prio=5 os_prio=0 tid=0xc2abac00 nid=0x77de waiting on condition [0xc10fe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-4" #408 prio=5 os_prio=0 tid=0xc0c20000 nid=0x77dd waiting on condition [0xc0bfe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-3" #407 prio=5 os_prio=0 tid=0xc0c31000 nid=0x77dc waiting on condition [0xc0dfe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-2" #406 prio=5 os_prio=0 tid=0xc0ef2800 nid=0x77db waiting on condition [0xc268c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-1" #405 prio=5 os_prio=0 tid=0xc0ef5400 nid=0x77da waiting on condition [0xc295c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "SecurityDomain ThreadGroup - 1" #70 prio=5 os_prio=0 tid=0xc6b91c00 nid=0x768b waiting on condition [0xc0103000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xc75a70c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "Remoting (anonymous) Accept" #64 daemon prio=5 os_prio=0 tid=0xc4d9c800 nid=0x7685 runnable [0xc06fe000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc76d8a50> (a sun.nio.ch.Util$2)
> 	- locked <0xc76d8a40> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76d8948> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) I/O-1" #63 daemon prio=5 os_prio=0 tid=0xc4d79800 nid=0x7684 runnable [0xc0918000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc76e4110> (a sun.nio.ch.Util$2)
> 	- locked <0xc76e4100> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76e4008> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) Accept" #32 daemon prio=5 os_prio=0 tid=0xc0e51000 nid=0x7665 runnable [0xc290b000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc7611ae0> (a sun.nio.ch.Util$2)
> 	- locked <0xc7611ad0> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76119d8> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) I/O-1" #31 daemon prio=5 os_prio=0 tid=0xc0e50c00 nid=0x7664 runnable [0xc2869000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc760fe80> (a sun.nio.ch.Util$2)
> 	- locked <0xc760fe70> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc760fd78> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Reference Reaper" #11 daemon prio=5 os_prio=0 tid=0xc401e800 nid=0x764d in Object.wait() [0xc34fe000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc74b4b20> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xc74b4b20> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at org.jboss.modules.ref.References$ReaperThread.run(References.java:64)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0xc4eaa800 nid=0x764b runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xc4ea7400 nid=0x764a waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xc4ea5c00 nid=0x7649 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xc4ea3c00 nid=0x7648 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xc4ea2400 nid=0x7647 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0xc4e88400 nid=0x7646 in Object.wait() [0xc697d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc7442988> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xc7442988> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xc4e85400 nid=0x7645 in Object.wait() [0xc6e51000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc727d4e8> (a java.lang.ref.Reference$Lock)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> 	- locked <0xc727d4e8> (a java.lang.ref.Reference$Lock)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0xf6506c00 nid=0x763f in Object.wait() [0xf6725000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at org.jboss.as.server.BootstrapImpl.startup(BootstrapImpl.java:171)
> 	at org.wildfly.core.embedded.EmbeddedStandaloneServerFactory$StandaloneServerImpl.start(EmbeddedStandaloneServerFactory.java:298)
> 	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.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:81)
> 	at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:55)
> 	at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:234)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> 	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:670)
> 	at org.jboss.as.cli.impl.CommandContextImpl.lambda$handle$0(CommandContextImpl.java:830)
> 	at org.jboss.as.cli.impl.CommandContextImpl$$Lambda$8/18944964.call(Unknown Source)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:829)
> 	at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:164)
> 	at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188)
> 	at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.stdoutTest(CLIEmbedServerTestCase.java:223)
> 	at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.testStdOutDefault(CLIEmbedServerTestCase.java:191)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	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)
> "VM Thread" os_prio=0 tid=0xc4e80c00 nid=0x7644 runnable 
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6510000 nid=0x7640 runnable 
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6511800 nid=0x7641 runnable 
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6512c00 nid=0x7642 runnable 
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6514000 nid=0x7643 runnable 
> "VM Periodic Task Thread" os_prio=0 tid=0xc4ec5800 nid=0x764c waiting on condition 
> JNI global references: 868
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 27 11:40:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 27 Feb 2017 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2090) CLIEmbedServerTestCase hang
In-Reply-To: <JIRA.12665797.1481052985000@Atlassian.JIRA>
References: <JIRA.12665797.1481052985000@Atlassian.JIRA>
	<JIRA.12665797.1481052985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665797.1481052985000.6286.1488213600385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills resolved WFCORE-2090.
-------------------------------
    Resolution: Cannot Reproduce Bug


> CLIEmbedServerTestCase hang
> ---------------------------
>
>                 Key: WFCORE-2090
>                 URL: https://issues.jboss.org/browse/WFCORE-2090
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It appears that CLIEmbedTestCase hung on 2016-12-06 at approx 643am EST. (Edit, see stack below. (A previous version of this suggested that the surefire logs indicated completion, but that was for the hostcontroller version of these tests.)
> A subsequent run, or running locally didn't cause the issue to occur.
> I'm leaving this hear as a placeholder for if / when this occurs again.
> Stack:
> [07:30:20][org.wildfly.core:wildfly-core-testsuite-manualmode] The build Pull Request::Pull request - Linux #5015 {buildId=36570} has been running for more than 75 minutes. Terminating...
> [07:30:25][org.wildfly.core:wildfly-core-testsuite-manualmode] Dumping threads before termination:
> [07:30:25][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 13627, PPID: 24231, Command line: /usr/java/jdk1.8.0_74/bin/java -Dagent.home.dir=/opt/buildAgent -Dagent.name=build03-el7 -Dagent.ownPort=9090 -Dagent.work.dir=/store/work/tc-work -Dbuild.number=5015 -Dbuild.vcs.number=0578e793a94cca04241a005583d43ad2b95a08f0 -Dbuild.vcs.number.1=0578e793a94cca04241a005583d43ad2b95a08f0 -Dbuild.vcs.number.WildFlyCore_WildFlyPullRequest=0578e793a94cca04241a005583d43ad2b95a08f0 -Dclassworlds.conf=/store/work/temp/buildTmp/teamcity.m2.conf -Dcom.jetbrains.maven.watcher.report.file=/store/work/temp/buildTmp/maven-build-info.xml -Djava.io.tmpdir=/store/work/temp/buildTmp -Dmaven.home=/opt/buildAgent/tools/maven32 -Dmaven.multiModuleProjectDirectory=/store/work/tc-work/4c983eca15c0017f -Dmaven.repo.local=/store/repository -Dteamcity.agent.cpuBenchmark=470 -Dteamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2 -Dteamcity.agent.dotnet.build_id=36570 -Dteamcity.auth.password=x8SPJnse6VqpvVQaNPLYBxuWRKejITxg -Dteamcity.auth.userId=TeamCityBuildId=36570 -Dteamcity.build.changedFiles.file=/store/work/temp/buildTmp/changedFiles1871277749042159253.txt -Dteamcity.build.checkoutDir=/store/work/tc-work/4c983eca15c0017f -Dteamcity.build.id=36570 -Dteamcity.build.properties.file=/store/work/temp/buildTmp/teamcity.build2954197549655995262.properties -Dteamcity.build.tempDir=/store/work/temp/buildTmp -Dteamcity.build.workingDir=/store/work/tc-work/4c983eca15c0017f -Dteamcity.buildConfName=Pull request - Linux -Dteamcity.buildType.id=WildFlyCore_PullRequest -Dteamcity.configuration.properties.file=/store/work/temp/buildTmp/teamcity.config7895286397916148834.properties -Dteamcity.maven.userSettings.path=/store/work/temp/buildTmp/maven_settings_6089771320309764773.xml -Dteamcity.maven.watcher.home=/opt/buildAgent/plugins/mavenPlugin/maven-watcher -Dteamcity.projectName=Pull Request -Dteamcity.runner.properties.file=/store/work/temp/buildTmp/teamcity.runner4428557639185750647.properties -Dteamcity.tests.recentlyFailedTests.file=/store/work/temp/buildTmp/testsToRunFirst3153555266480301879.txt -Dteamcity.version=9.1.7 (build 37573) -Xms512M -Xmx768M -classpath /opt/buildAgent/tools/maven32/boot/plexus-classworlds-2.5.2.jar: org.codehaus.plexus.classworlds.launcher.Launcher -f /store/work/tc-work/4c983eca15c0017f/pom.xml -B clean install -s /store/work/temp/buildTmp/maven_settings_6089771320309764773.xml -fae -U -DallTests -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dipv6 -Dorg.jboss.model.test.maven.repository.urls=http://repository.ci.wildfly.org/content/groups/public/
> [07:30:26]
> [org.wildfly.core:wildfly-core-testsuite-manualmode] 2016-12-06 06:30:27
> Full thread dump Java HotSpot(TM) Server VM (25.74-b02 mixed mode):
> "Attach Listener" #882 daemon prio=9 os_prio=0 tid=0xb4304800 nid=0x7843 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Thread-271" #880 prio=5 os_prio=0 tid=0xab874c00 nid=0x763d runnable [0xaedaa000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:255)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> 	- locked <0xd7251740> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> 	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> 	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> 	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> 	- locked <0xd7256708> (a java.io.InputStreamReader)
> 	at java.io.InputStreamReader.read(InputStreamReader.java:184)
> 	at java.io.BufferedReader.fill(BufferedReader.java:161)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:324)
> 	- locked <0xd7256708> (a java.io.InputStreamReader)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:389)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66)
> "Thread-270" #879 prio=5 os_prio=0 tid=0xab107c00 nid=0x763c runnable [0xaed59000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:255)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> 	- locked <0xd724f6a0> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> 	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> 	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> 	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> 	- locked <0xd7253b38> (a java.io.InputStreamReader)
> 	at java.io.InputStreamReader.read(InputStreamReader.java:184)
> 	at java.io.BufferedReader.fill(BufferedReader.java:161)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:324)
> 	- locked <0xd7253b38> (a java.io.InputStreamReader)
> 	at java.io.BufferedReader.readLine(BufferedReader.java:389)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66)
> "ThreadedStreamConsumer" #878 prio=5 os_prio=0 tid=0xad9ed400 nid=0x763a waiting on condition [0xaeefe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xd72411b0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:68)
> 	at java.lang.Thread.run(Thread.java:745)
> "pool-86-thread-1" #805 prio=5 os_prio=0 tid=0xab107400 nid=0x66dc in Object.wait() [0xaedfb000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396)
> 	- locked <0xd724d440> (a java.lang.UNIXProcess)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:202)
> 	at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:141)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:471)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:380)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$300(ForkStarter.java:88)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:315)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:306)
> 	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)
> "resolver-5" #24 daemon prio=5 os_prio=0 tid=0xb0e25400 nid=0x355d waiting on condition [0xaee4c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-4" #23 daemon prio=5 os_prio=0 tid=0xb3b8b400 nid=0x355c waiting on condition [0xb0290000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-3" #22 daemon prio=5 os_prio=0 tid=0xb3b8a400 nid=0x355b waiting on condition [0xb13b2000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-2" #21 daemon prio=5 os_prio=0 tid=0xb3b8a000 nid=0x355a waiting on condition [0xb168f000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "resolver-1" #20 daemon prio=5 os_prio=0 tid=0xb0ebc000 nid=0x3559 waiting on condition [0xb16e0000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xb94dbaa8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "process reaper" #10 daemon prio=10 os_prio=0 tid=0xb11b1400 nid=0x354e runnable [0xb16f9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.UNIXProcess.waitForProcessExit(Native Method)
> 	at java.lang.UNIXProcess.lambda$initStreams$3(UNIXProcess.java:290)
> 	at java.lang.UNIXProcess$$Lambda$7/11278477.run(Unknown Source)
> 	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)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0xb44aa800 nid=0x3548 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xb44a7000 nid=0x3547 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xb44a5c00 nid=0x3546 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xb44a3c00 nid=0x3545 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xb44a2400 nid=0x3544 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0xb4488000 nid=0x3543 in Object.wait() [0xb687d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xb8759ca0> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xb4485400 nid=0x3542 in Object.wait() [0xb6b7d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> 	- locked <0xb8761898> (a java.lang.ref.Reference$Lock)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0xf6508800 nid=0x353c waiting on condition [0xf672a000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xbc759d20> (a java.util.concurrent.FutureTask)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> 	at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:327)
> 	at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:178)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:990)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:824)
> 	at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:722)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 	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.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)
> "VM Thread" os_prio=0 tid=0xb4480c00 nid=0x3541 runnable 
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6512000 nid=0x353d runnable 
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6513400 nid=0x353e runnable 
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6514c00 nid=0x353f runnable 
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6516000 nid=0x3540 runnable 
> "VM Periodic Task Thread" os_prio=0 tid=0xb44bd800 nid=0x3549 waiting on condition 
> JNI global references: 289
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 30267, PPID: 13627, Command line: /bin/sh -c cd /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode && /usr/java/jdk1.8.0_74/jre/bin/java -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/wildfly-core -jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefirebooter8497614206686950307.jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire7659716555864739391tmp /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire_1307355743037353978607tmp
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] Failed to locate jps tool. No thread dump information is available
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] PID: 30270, PPID: 30267, Command line: /usr/java/jdk1.8.0_74/jre/bin/java -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/wildfly-core -jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefirebooter8497614206686950307.jar /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire7659716555864739391tmp /store/work/tc-work/4c983eca15c0017f/testsuite/manualmode/target/surefire/surefire_1307355743037353978607tmp
> [07:30:26]
> [org.wildfly.core:wildfly-core-testsuite-manualmode] 2016-12-06 06:30:27
> Full thread dump Java HotSpot(TM) Server VM (25.74-b02 mixed mode):
> "Attach Listener" #435 daemon prio=9 os_prio=0 tid=0xc4d5dc00 nid=0x785a waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "ServerService Thread Pool -- 16" #434 prio=5 os_prio=0 tid=0xc0c51800 nid=0x77f7 waiting on condition [0xbfcf6000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerService Thread Pool -- 15" #433 prio=5 os_prio=0 tid=0xc0c33c00 nid=0x77f6 waiting on condition [0xc1c5b000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerService Thread Pool -- 13" #431 prio=5 os_prio=0 tid=0xc0c00c00 nid=0x77f4 waiting on condition [0xc1afe000]
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "Timer-4" #430 prio=5 os_prio=0 tid=0xc0ef4000 nid=0x77f3 in Object.wait() [0xc035c000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xdcbaebc0> (a java.util.TaskQueue)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.util.TimerThread.mainLoop(Timer.java:526)
> 	- locked <0xdcbaebc0> (a java.util.TaskQueue)
> 	at java.util.TimerThread.run(Timer.java:505)
> "management Accept" #429 prio=5 os_prio=0 tid=0xc46c0400 nid=0x77f2 runnable [0xc1cac000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba7270> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba7260> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba7168> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-2" #428 prio=5 os_prio=0 tid=0xc44b6c00 nid=0x77f1 runnable [0xbf93e000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba5808> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba57f8> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba5700> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "management I/O-1" #427 prio=5 os_prio=0 tid=0xc0c32000 nid=0x77f0 runnable [0xc03ad000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xdcba3da0> (a sun.nio.ch.Util$2)
> 	- locked <0xdcba3d90> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xdcba3c98> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "MSC service thread 14-5" #409 prio=5 os_prio=0 tid=0xc0efc800 nid=0x77e7 waiting on condition [0xc0bad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "ServerService Thread Pool -- 4" #418 prio=5 os_prio=0 tid=0xc0ef3000 nid=0x77e6 waiting on condition [0xc09ba000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3ad0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "ServerDeploymentRepository-temp-threads - 1" #413 daemon prio=5 os_prio=0 tid=0xbe74b800 nid=0x77e1 waiting on condition [0xc29ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xdc7e3e88> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "MSC service thread 14-8" #412 prio=5 os_prio=0 tid=0xbe738400 nid=0x77e0 waiting on condition [0xc05ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-7" #411 prio=5 os_prio=0 tid=0xc0efa400 nid=0x77df waiting on condition [0xc10ad000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-6" #410 prio=5 os_prio=0 tid=0xc2abac00 nid=0x77de waiting on condition [0xc10fe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-4" #408 prio=5 os_prio=0 tid=0xc0c20000 nid=0x77dd waiting on condition [0xc0bfe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-3" #407 prio=5 os_prio=0 tid=0xc0c31000 nid=0x77dc waiting on condition [0xc0dfe000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-2" #406 prio=5 os_prio=0 tid=0xc0ef2800 nid=0x77db waiting on condition [0xc268c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "MSC service thread 14-1" #405 prio=5 os_prio=0 tid=0xc0ef5400 nid=0x77da waiting on condition [0xc295c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xe5035350> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> "SecurityDomain ThreadGroup - 1" #70 prio=5 os_prio=0 tid=0xc6b91c00 nid=0x768b waiting on condition [0xc0103000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0xc75a70c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	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)
> "Remoting (anonymous) Accept" #64 daemon prio=5 os_prio=0 tid=0xc4d9c800 nid=0x7685 runnable [0xc06fe000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc76d8a50> (a sun.nio.ch.Util$2)
> 	- locked <0xc76d8a40> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76d8948> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) I/O-1" #63 daemon prio=5 os_prio=0 tid=0xc4d79800 nid=0x7684 runnable [0xc0918000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc76e4110> (a sun.nio.ch.Util$2)
> 	- locked <0xc76e4100> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76e4008> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) Accept" #32 daemon prio=5 os_prio=0 tid=0xc0e51000 nid=0x7665 runnable [0xc290b000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc7611ae0> (a sun.nio.ch.Util$2)
> 	- locked <0xc7611ad0> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc76119d8> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Remoting (anonymous) I/O-1" #31 daemon prio=5 os_prio=0 tid=0xc0e50c00 nid=0x7664 runnable [0xc2869000]
>    java.lang.Thread.State: RUNNABLE
> 	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> 	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> 	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> 	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> 	- locked <0xc760fe80> (a sun.nio.ch.Util$2)
> 	- locked <0xc760fe70> (a java.util.Collections$UnmodifiableSet)
> 	- locked <0xc760fd78> (a sun.nio.ch.EPollSelectorImpl)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> 	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:515)
> "Reference Reaper" #11 daemon prio=5 os_prio=0 tid=0xc401e800 nid=0x764d in Object.wait() [0xc34fe000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc74b4b20> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xc74b4b20> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at org.jboss.modules.ref.References$ReaperThread.run(References.java:64)
> "Service Thread" #8 daemon prio=9 os_prio=0 tid=0xc4eaa800 nid=0x764b runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0xc4ea7400 nid=0x764a waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0xc4ea5c00 nid=0x7649 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0xc4ea3c00 nid=0x7648 waiting on condition [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0xc4ea2400 nid=0x7647 runnable [0x00000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=0 tid=0xc4e88400 nid=0x7646 in Object.wait() [0xc697d000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc7442988> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
> 	- locked <0xc7442988> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
> "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0xc4e85400 nid=0x7645 in Object.wait() [0xc6e51000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xc727d4e8> (a java.lang.ref.Reference$Lock)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
> 	- locked <0xc727d4e8> (a java.lang.ref.Reference$Lock)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
> "main" #1 prio=5 os_prio=0 tid=0xf6506c00 nid=0x763f in Object.wait() [0xf6725000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at java.lang.Object.wait(Object.java:502)
> 	at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> 	- locked <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> 	- locked <0xe5064e20> (a org.jboss.as.server.BootstrapImpl$FutureServiceContainer)
> 	at org.jboss.as.server.BootstrapImpl.startup(BootstrapImpl.java:171)
> 	at org.wildfly.core.embedded.EmbeddedStandaloneServerFactory$StandaloneServerImpl.start(EmbeddedStandaloneServerFactory.java:298)
> 	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.wildfly.core.embedded.EmbeddedManagedProcessImpl.invokeOnServer(EmbeddedManagedProcessImpl.java:81)
> 	at org.wildfly.core.embedded.EmbeddedManagedProcessImpl.start(EmbeddedManagedProcessImpl.java:55)
> 	at org.jboss.as.cli.embedded.EmbedServerHandler.doHandle(EmbedServerHandler.java:234)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:89)
> 	at org.jboss.as.cli.impl.CommandExecutor.execute(CommandExecutor.java:670)
> 	at org.jboss.as.cli.impl.CommandContextImpl.lambda$handle$0(CommandContextImpl.java:830)
> 	at org.jboss.as.cli.impl.CommandContextImpl$$Lambda$8/18944964.call(Unknown Source)
> 	at org.jboss.as.cli.impl.CommandContextImpl.execute(CommandContextImpl.java:882)
> 	at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:829)
> 	at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:164)
> 	at org.jboss.as.test.integration.management.util.CLIWrapper.sendLine(CLIWrapper.java:188)
> 	at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.stdoutTest(CLIEmbedServerTestCase.java:223)
> 	at org.jboss.as.test.manualmode.management.cli.CLIEmbedServerTestCase.testStdOutDefault(CLIEmbedServerTestCase.java:191)
> 	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.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	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)
> "VM Thread" os_prio=0 tid=0xc4e80c00 nid=0x7644 runnable 
> "GC task thread#0 (ParallelGC)" os_prio=0 tid=0xf6510000 nid=0x7640 runnable 
> "GC task thread#1 (ParallelGC)" os_prio=0 tid=0xf6511800 nid=0x7641 runnable 
> "GC task thread#2 (ParallelGC)" os_prio=0 tid=0xf6512c00 nid=0x7642 runnable 
> "GC task thread#3 (ParallelGC)" os_prio=0 tid=0xf6514000 nid=0x7643 runnable 
> "VM Periodic Task Thread" os_prio=0 tid=0xc4ec5800 nid=0x764c waiting on condition 
> JNI global references: 868
> [07:30:26][org.wildfly.core:wildfly-core-testsuite-manualmode] 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Mon Feb 27 11:40:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 27 Feb 2017 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2330) JBoss-CLI "deploy -l"
 always returns exit code 1 even when it succeeds
In-Reply-To: <JIRA.12678941.1488158534000@Atlassian.JIRA>
References: <JIRA.12678941.1488158534000@Atlassian.JIRA>
	<JIRA.12678941.1488158534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678941.1488158534000.6290.1488213600503@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-2330:
--------------------------------------------

    Assignee: Masafumi Miura


> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeeds
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-2330
>                 URL: https://issues.jboss.org/browse/WFCORE-2330
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Masafumi Miura
>            Assignee: Masafumi Miura
>
> JBoss-CLI "deploy -l" always returns exit code 1 even when it succeededs.
> It looks that DeploymentHandler.listDeployments() always throws CommandFormatException and this causes the "deploy -l" command returns exit code 1.
> {code:java|title=cli/src/main/java/org/jboss/as/cli/handlers/DeploymentHandler.java}
>  55     protected void listDeployments(CommandContext ctx, boolean l) throws CommandFormatException {
>  56         if(!l) {
>  57             printList(ctx, Util.getDeployments(ctx.getModelControllerClient()), l);
>  58             return;
>  59         }
>  60         final ModelControllerClient client = ctx.getModelControllerClient();
>  61         final List<String> names = Util.getDeployments(client);
>  62         if(names.isEmpty()) {
>  63             return;
>  64         }
>  65 
>  66         final StrictSizeTable table = new StrictSizeTable(names.size());
>  67         final List<Property> descriptions = getDeploymentDescriptions(ctx, names).asPropertyList();
>  68         for(Property prop : descriptions) {
>  69             final ModelNode step = prop.getValue();
>  70             if(step.hasDefined(Util.RESULT)) {
>  71                 final ModelNode result = step.get(Util.RESULT);
>  72                 table.addCell(Util.NAME, result.get(Util.NAME).asString());
>  73                 table.addCell(Util.RUNTIME_NAME, result.get(Util.RUNTIME_NAME).asString());
>  74                 if(result.has(Util.ENABLED)) {
>  75                     table.addCell(Util.ENABLED, result.get(Util.ENABLED).asString());
>  76                 }
>  77                 if(result.has(Util.STATUS)) {
>  78                     table.addCell(Util.STATUS, result.get(Util.STATUS).asString());
>  79                 }
>  80             }
>  81             if(!table.isAtLastRow()) {
>  82                 table.nextRow();
>  83             }
>  84         }
>  85         throw new CommandFormatException(table.toString());   // -> CommandFormatException is always thrown. This looks a root cause.
>  86     }
> {code}
> {code:java|title=cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java}
>  907     public void handleSafe(String line) {
>  908         exitCode = 0;
>  909         try {
>  910             handle(line);
>  911         } catch(Throwable t) {
>  912             error(Util.getMessagesFromThrowable(t));   // -> This is invoked when CommandFormatException happened in the above listDeployments. 
>  913         }
>  914     }
>   :
>  993     protected void error(String message) {
>  994         this.exitCode = 1;
>  995         printLine(message);
>  996     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 11:41:00 2017
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 27 Feb 2017 11:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2328) CLI connect command should
 accept a --bind parameter
In-Reply-To: <JIRA.12678845.1487964070000@Atlassian.JIRA>
References: <JIRA.12678845.1487964070000@Atlassian.JIRA>
	<JIRA.12678845.1487964070000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678845.1487964070000.6301.1488213660188@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-2328:
--------------------------------------------

    Assignee: Jean-Francois Denise


> CLI connect command should accept a --bind parameter
> ----------------------------------------------------
>
>                 Key: WFCORE-2328
>                 URL: https://issues.jboss.org/browse/WFCORE-2328
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>            Priority: Minor
>
> When you launch the CLI you can pass a --bind=xxx param which then controls the client side bind address used for connections. But you can't specify this with the connect command itself.
> This is minor; I just noticed it while experimenting with the fix for WFCORE-2225 when I wanted to confirm the fix was working by using the CLI.
> Also, I noticed that if I did a "connect --bind=192.168.1.10" the CLI accepted the invalide command.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 11:50:00 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Mon, 27 Feb 2017 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1187) Embedded server start /
 stop / start with new --jboss-home continues to refer to previous
 server.log
In-Reply-To: <JIRA.12595438.1449268036000@Atlassian.JIRA>
References: <JIRA.12595438.1449268036000@Atlassian.JIRA>
	<JIRA.12595438.1449268036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595438.1449268036000.6359.1488214200180@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369796#comment-13369796 ] 

Ken Wills commented on WFCORE-1187:
-----------------------------------

Just retested this to validate it was actually still occuring.

The remaining issue with this is, if you have embedded A & B, starting A will correctly log to A's server.log, then stopping A, and starting B will use A's log, unless B is reloaded. This sequence continues.

Should be an easy enough one to track down.

> Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1187
>                 URL: https://issues.jboss.org/browse/WFCORE-1187
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> - start-embedded-server --jboss-home=/foo/bar1
> - stop-embedded-server
> - start-embedded-server --jboss-home=/foo/bar2
> -- server.log in /foo/bar1/standalone/logs/server.log is still written to.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 12:07:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 27 Feb 2017 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.6442.1488215220655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-8241.
----------------------------
    Fix Version/s: 11.0.0.Alpha1
       Resolution: Duplicate Issue


> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Mon Feb 27 12:07:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Feb 2017 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2339) Restore configurability of
 the management client bind address
In-Reply-To: <JIRA.12679068.1488215211000@Atlassian.JIRA>
References: <JIRA.12679068.1488215211000@Atlassian.JIRA>
	<JIRA.12679068.1488215211919@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679068.1488215211000.6446.1488215220750@Atlassian.JIRA>

Brian Stansberry created WFCORE-2339:
----------------------------------------

             Summary: Restore configurability of the management client bind address
                 Key: WFCORE-2339
                 URL: https://issues.jboss.org/browse/WFCORE-2339
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management, Remoting
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Blocker
             Fix For: 3.0.0.CR1


It looks like the AS7-6223 functionality was dropped in the move to Remoting 5:

https://github.com/wildfly/wildfly-core/blame/master/protocol/src/main/java/org/jboss/as/protocol/ProtocolConnectionUtils.java#L166

Something needs to be restored or we have a regression.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 12:11:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 27 Feb 2017 12:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8241) EJB deployments with Elytron
 SD collides in EJB3 SD service
In-Reply-To: <JIRA.12678871.1487979993000@Atlassian.JIRA>
References: <JIRA.12678871.1487979993000@Atlassian.JIRA>
	<JIRA.12678871.1487979993000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678871.1487979993000.6496.1488215460519@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369814#comment-13369814 ] 

Jan Kalina commented on WFLY-8241:
----------------------------------

Thanks, confirmed. I was using old build. Sorry.

> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
>                 Key: WFLY-8241
>                 URL: https://issues.jboss.org/browse/WFLY-8241
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>         Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/EJBDefaultSecurityDomainProcessor.java#L107
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> 	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: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> 	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  Mon Feb 27 12:44:01 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 27 Feb 2017 12:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1451) NPE when building KieBase
 with OOPath in a declared window
In-Reply-To: <JIRA.12678839.1487959567000@Atlassian.JIRA>
References: <JIRA.12678839.1487959567000@Atlassian.JIRA>
	<JIRA.12678839.1487959567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678839.1487959567000.6704.1488217441584@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369834#comment-13369834 ] 

Mario Fusco commented on DROOLS-1451:
-------------------------------------

Since an oopath constraint is implemented through one or more FromNode it is not technically possible to allow to use it inside a declared window, in the same way as a declared window cannot contain a join condition. 

In fact to let this work the resulting rete network should be something like:

{code}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
    [ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
        [LeftInputAdapterNode(5)] on Partition(1)
            [JoinNode(6) - [ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent]] on Partition(1)
                [ReactiveFromNode(7) :: MessageEvent/getMsg{message == "Ping"}] on Partition(1)
                    [RuleTerminalNode(8): rule=R] on Partition(1)
    [ObjectTypeNode(3)::EntryPoint::DEFAULT objectType=[ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent] expiration=3000ms ] on Partition(MAIN)
        [WindowNode(4) constraints=[]] on Partition(1)
            [JoinNode(6) - [ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent]] on Partition(1)
{code}

with the WindowNode feeding the JoinNode of the rule where the declared window is used and the ReactiveFromNode implementing the oopath, below that JoinNode itself. This is clearly not possible.

> NPE when building KieBase with OOPath in a declared window
> ----------------------------------------------------------
>
>                 Key: DROOLS-1451
>                 URL: https://issues.jboss.org/browse/DROOLS-1451
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.0.0.Beta6
>         Environment: Reproducible with 7.0.0-SNAPSHOT.
>            Reporter: Marek Winkler
>            Assignee: Mario Fusco
>         Attachments: oopath-cep-stacktrace.txt
>
>
> When using an OOPath expression in a declared window (does not matter if a length or a time window), a NPE is thrown. For instance, a rule such as:
> {code}
> declare window Pings
>   MessageEvent( /msg{ message == 'Ping' } ) over window:length( 2 )
> end
> rule R when
>   $messageEvent: MessageEvent() from window Pings
> then
>   events.add( $messageEvent );
> end
> {code}
> produces the following exception (see the attachment for the full stacktrace) when building the KieBase:
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.builder.WindowReferenceBuilder.build(WindowReferenceBuilder.java:40)
> 	at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:116)
> 	at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:77)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> 	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:164)
> 	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
> 	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> ...
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:630)
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 15:08:00 2017
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 27 Feb 2017 15:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-955) Regression in parsing
 username in LdapExtLoginModule
In-Reply-To: <JIRA.12649056.1473229910000@Atlassian.JIRA>
References: <JIRA.12649056.1473229910000@Atlassian.JIRA>
	<JIRA.12649056.1473229910000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649056.1473229910000.7436.1488226080339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen closed SECURITY-955.
-----------------------------------
    Fix Version/s: PicketBox_5_0_0.Beta1
       Resolution: Done


The commit that was missing in PicketBox/master was merged.

> Regression in parsing username in LdapExtLoginModule
> ----------------------------------------------------
>
>                 Key: SECURITY-955
>                 URL: https://issues.jboss.org/browse/SECURITY-955
>             Project: PicketBox 
>          Issue Type: Bug
>    Affects Versions: PicketBox_5_0_0.Alpha3
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>            Priority: Blocker
>             Fix For: PicketBox_5_0_0.Beta1
>
>
> In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE.
> It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3).
> We request blocker flag because:
> * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0
> * All users cannot authenticate to application despite of valid EAP configuration
> * Authetication failure caused by NPE is logged to server log
> Thrown NPE:
> {code}
> java.lang.NullPointerException
>         at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963)
>         at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342)
>         at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283)
> {code}
> [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13160168



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 15:10:00 2017
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 27 Feb 2017 15:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-811) NullPointerException in
 DeploymentRoleToRolesMappingProvider
In-Reply-To: <JIRA.12536263.1395914971000@Atlassian.JIRA>
References: <JIRA.12536263.1395914971000@Atlassian.JIRA>
	<JIRA.12536263.1395914971000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536263.1395914971000.7453.1488226200292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen resolved SECURITY-811.
-------------------------------------
    Fix Version/s: PicketBox_5_0_0.Beta1
       Resolution: Done


> NullPointerException in DeploymentRoleToRolesMappingProvider
> ------------------------------------------------------------
>
>                 Key: SECURITY-811
>                 URL: https://issues.jboss.org/browse/SECURITY-811
>             Project: PicketBox 
>          Issue Type: Bug
>          Components: JBossSX
>    Affects Versions: JBossSecurity_2.0.8.Final
>            Reporter: Chao Wang
>            Assignee: Peter Skopek
>            Priority: Minor
>             Fix For: PicketBox_5_0_0.Beta1
>
>         Attachments: SECURITY-811-picketbox.patch, SECURITY-811.patch
>
>
> {code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
> RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
> for (Role r: assignedRoles.getRoles()) {
> {code}
> A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 15:10:00 2017
From: issues at jboss.org (Stefan Guilhen (JIRA))
Date: Mon, 27 Feb 2017 15:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-913) NPE if use
	LdapExtLoginModule in j2se
In-Reply-To: <JIRA.12585352.1442570272000@Atlassian.JIRA>
References: <JIRA.12585352.1442570272000@Atlassian.JIRA>
	<JIRA.12585352.1442570272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585352.1442570272000.7456.1488226200527@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen resolved SECURITY-913.
-------------------------------------
    Fix Version/s: PicketBox_5_0_0.Beta1
                       (was: PicketBox_5_0_0.Alpha1)
       Resolution: Done


> NPE if use LdapExtLoginModule in j2se
> -------------------------------------
>
>                 Key: SECURITY-913
>                 URL: https://issues.jboss.org/browse/SECURITY-913
>             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
>
>         Attachments: picketbox-j2se.zip
>
>
> Use LdapExtLoginModule in j2se with condifg:
> {code}
> <?xml version='1.0'?> 
>  
> <policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>          xsi:schemaLocation="urn:jboss:security-config:5.0"
>          xmlns="urn:jboss:security-config:5.0"
>          xmlns:jbxb="urn:jboss:security-config:5.0">
>          
>     <application-policy name = "Sample-Ldap"> 
>        <authentication>
>           <login-module code = "org.jboss.security.auth.spi.LdapExtLoginModule" flag = "required">  
>               <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
>               <module-option name="java.naming.provider.url">ldap://10.66.218.46:389</module-option>
>               <module-option name="java.naming.security.authentication">simple</module-option>
>               <module-option name="bindDN">cn=Manager,dc=example,dc=com</module-option>
>               <module-option name="bindCredential">redhat</module-option>
>               <module-option name="baseCtxDN">ou=Customers,dc=example,dc=com</module-option>
>               <module-option name="baseFilter">(uid={0})</module-option>
>               <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option>
>               <module-option name="roleFilter">(uniqueMember={1})</module-option>
>               <module-option name="roleAttributeID">cn</module-option>
>           </login-module> 
>        </authentication> 
>     </application-policy>  
>      
> </policy> 
> {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  Mon Feb 27 15:40:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 27 Feb 2017 15:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.7567.1488228000354@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369918#comment-13369918 ] 

Martin Choma commented on WFLY-8238:
------------------------------------

[~thofman], will you take care globally, as in case of WFLY-8070 ?

> 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  Mon Feb 27 15:45:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Feb 2017 15:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.7576.1488228300443@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369912#comment-13369912 ] 

Brian Stansberry edited comment on WFCORE-2292 at 2/27/17 3:44 PM:
-------------------------------------------------------------------

I'm rejecting the PR to get this issue in the correct state because at this stage the PR says Do not Merge.


was (Author: brian.stansberry):
I'm rejecting the PR to get this issue in the correct because at this stage the PR says Do not Merge.

> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 15:46:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Mon, 27 Feb 2017 15:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8252) HttpServletRequest.logout()
 doesn't work with Elytron
In-Reply-To: <JIRA.12679097.1488228317000@Atlassian.JIRA>
References: <JIRA.12679097.1488228317000@Atlassian.JIRA>
	<JIRA.12679097.1488228317229@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679097.1488228317000.7613.1488228360627@Atlassian.JIRA>

Josef Cacek created WFLY-8252:
---------------------------------

             Summary: HttpServletRequest.logout() doesn't work with Elytron
                 Key: WFLY-8252
                 URL: https://issues.jboss.org/browse/WFLY-8252
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow), Security
            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  Mon Feb 27 16:12:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Feb 2017 16:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1507) Expose the ModelController
 via a capability
In-Reply-To: <JIRA.12616768.1461611433000@Atlassian.JIRA>
References: <JIRA.12616768.1461611433000@Atlassian.JIRA>
	<JIRA.12616768.1461611433000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616768.1461611433000.7695.1488229920380@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369933#comment-13369933 ] 

Brian Stansberry commented on WFCORE-1507:
------------------------------------------

This is partially complete via https://github.com/wildfly/wildfly-core/pull/2205. I'm not resolving it yet as I also want to break out the getNotificationRegistry() method, as that's valid for use by extensions while the rest of ModelController is not.

> Expose the ModelController via a capability
> -------------------------------------------
>
>                 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<ModelController>. 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  Mon Feb 27 16:13:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 27 Feb 2017 16:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1964) Internal
 ModelControllerClient should bypass access control by default
In-Reply-To: <JIRA.12660290.1478636332000@Atlassian.JIRA>
References: <JIRA.12660290.1478636332000@Atlassian.JIRA>
	<JIRA.12660290.1478636332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660290.1478636332000.7702.1488229980500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-1964.
--------------------------------------
      Assignee: Brian Stansberry  (was: Darran Lofthouse)
    Resolution: Done


If https://github.com/wildfly/wildfly-core/pull/2205/commits/0ed7c89904db057019cdb77ef24b3d117632d42b isn't what you had in mind here, please re-open.

> Internal ModelControllerClient should bypass access control by default
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-1964
>                 URL: https://issues.jboss.org/browse/WFCORE-1964
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 3.0.0.Beta6
>
>
> This is continuing compatibility where in-vm clients can perform actions without triggering management access control.
> It would be nice also if we could find a way to make it possible to selectively disable this for cases where we want identity propagation between applications and the management tier.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 16:34:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 27 Feb 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8202) CS tool,
	format Missing required option
In-Reply-To: <JIRA.12678321.1487772564000@Atlassian.JIRA>
References: <JIRA.12678321.1487772564000@Atlassian.JIRA>
	<JIRA.12678321.1487772564000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678321.1487772564000.7802.1488231240228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned WFLY-8202:
-----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> 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  Mon Feb 27 17:08:00 2017
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Mon, 27 Feb 2017 17:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8253) Premature validation in
	Naming subsystem
In-Reply-To: <JIRA.12679100.1488230171000@Atlassian.JIRA>
References: <JIRA.12679100.1488230171000@Atlassian.JIRA>
	<JIRA.12679100.1488230171000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679100.1488230171000.7939.1488233280056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins moved JBEAP-9166 to WFLY-8253:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8253  (was: JBEAP-9166)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Naming
                           (was: Naming)
    Affects Version/s:     (was: 7.1.0.DR8)


> Premature validation in Naming subsystem
> ----------------------------------------
>
>                 Key: WFLY-8253
>                 URL: https://issues.jboss.org/browse/WFLY-8253
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> If composite operation is performed on naming subsystem and member operation are in wrong order the composite operation is not performed and all changes are rolled back. See https://issues.jboss.org/browse/JBEAP-6418?focusedCommentId=13314862&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13314862
> and https://issues.jboss.org/browse/JBEAP-6418?focusedCommentId=13314879&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13314879



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 17:09:00 2017
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Mon, 27 Feb 2017 17:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8253) Premature validation in
	Naming subsystem
In-Reply-To: <JIRA.12679100.1488230171000@Atlassian.JIRA>
References: <JIRA.12679100.1488230171000@Atlassian.JIRA>
	<JIRA.12679100.1488230171000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679100.1488230171000.7941.1488233340500@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins reopened WFLY-8253:
-----------------------------------


> Premature validation in Naming subsystem
> ----------------------------------------
>
>                 Key: WFLY-8253
>                 URL: https://issues.jboss.org/browse/WFLY-8253
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> If composite operation is performed on naming subsystem and member operation are in wrong order the composite operation is not performed and all changes are rolled back. See https://issues.jboss.org/browse/JBEAP-6418?focusedCommentId=13314862&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13314862
> and https://issues.jboss.org/browse/JBEAP-6418?focusedCommentId=13314879&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13314879



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 19:12:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Mon, 27 Feb 2017 19:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1330) XA Stats not updated when
 the provided XAResource already implements XAResourceWrapper
In-Reply-To: <JIRA.12649756.1473686946000@Atlassian.JIRA>
References: <JIRA.12649756.1473686946000@Atlassian.JIRA>
	<JIRA.12649756.1473686946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649756.1473686946000.8170.1488240720351@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369980#comment-13369980 ] 

Kabir Khan commented on JBJCA-1330:
-----------------------------------

[~rsvoboda] This was reported on the Alpha readiness spreadsheet, but appears to already have been fixed in DR11

CC [~jmesnil]

> XA Stats not updated when the provided  XAResource already implements XAResourceWrapper
> ---------------------------------------------------------------------------------------
>
>                 Key: JBJCA-1330
>                 URL: https://issues.jboss.org/browse/JBJCA-1330
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: WildFly/IronJacamar 1.3.4.Final
>            Reporter: Jeff Mesnil
>            Assignee: Stefano Maestri
>             Fix For: WildFly/IronJacamar 1.4.1.Final
>
>
> Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition.
> I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected.
> However xa stats (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated.
> The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2].
> Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats.
> [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-factory-stats
> [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/src/main/java/org/jboss/activemq/artemis/wildfly/integration/WildFlyActiveMQXAResourceWrapper.java
> [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/org/jboss/jca/core/connectionmanager/tx/TxConnectionManagerImpl.java#L714



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Feb 27 19:16:00 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 27 Feb 2017 19:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8252) HttpServletRequest.logout()
 doesn't work with Elytron
In-Reply-To: <JIRA.12679097.1488228317000@Atlassian.JIRA>
References: <JIRA.12679097.1488228317000@Atlassian.JIRA>
	<JIRA.12679097.1488228317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679097.1488228317000.8184.1488240960278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13369982#comment-13369982 ] 

Stuart Douglas commented on WFLY-8252:
--------------------------------------

https://github.com/wildfly-security/elytron-web/pull/78 https://github.com/wildfly-security/wildfly-elytron/pull/696

> 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 Feb 28 02:06:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 28 Feb 2017 02:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8254) Changing
 sasl-authentication-factory in management interface ends in reload-required
 state
In-Reply-To: <JIRA.12679125.1488265529000@Atlassian.JIRA>
References: <JIRA.12679125.1488265529000@Atlassian.JIRA>
	<JIRA.12679125.1488265529361@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679125.1488265529000.8518.1488265560430@Atlassian.JIRA>

Martin Choma created WFLY-8254:
----------------------------------

             Summary: Changing sasl-authentication-factory in management interface ends in reload-required state
                 Key: WFLY-8254
                 URL: https://issues.jboss.org/browse/WFLY-8254
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Martin Choma
            Assignee: Darran Lofthouse


Attribute sasl-authentication-factory is described as follows
{code}
    "sasl-authentication-factory" => {
        "type" => STRING,
        "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
        "expressions-allowed" => false,
        "required" => false,
        "nillable" => true,
        "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
        "min-length" => 1L,
        "max-length" => 2147483647L
    }
{code}

Documenation [1] says:
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.

But when I try to change it I get:
{code}
[standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
{code}

Probably some proper value for "restart-required" should be used. "restart-required" => "all-services" ?

[1] https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 02:19:00 2017
From: issues at jboss.org (Tomas Hofman (JIRA))
Date: Tue, 28 Feb 2017 02:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.8583.1488266340446@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370020#comment-13370020 ] 

Tomas Hofman commented on WFLY-8238:
------------------------------------

[~mchoma] sure I can.

> 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  Tue Feb 28 02:24:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 28 Feb 2017 02:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8255) New EJB Authentication tests
 (in AS TS) fail with Elytron profile
In-Reply-To: <JIRA.12679129.1488266613000@Atlassian.JIRA>
References: <JIRA.12679129.1488266613000@Atlassian.JIRA>
	<JIRA.12679129.1488266613732@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679129.1488266613000.8617.1488266640354@Atlassian.JIRA>

Josef Cacek created WFLY-8255:
---------------------------------

             Summary: New EJB Authentication tests (in AS TS) fail with Elytron profile
                 Key: WFLY-8255
                 URL: https://issues.jboss.org/browse/WFLY-8255
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite, Security
            Reporter: Josef Cacek
            Assignee: Darran Lofthouse
            Priority: Critical


The newly introduced authentication tests ({{AuthenticationElytronTestCase}}, {{AuthenticationTestCase}}) in {{org.jboss.as.test.integration.ejb.security}} package fail when executed with Elytron AS TS profile.

{noformat}
cd testsuite/integration/basic
mvn clean test -Dtest=org.jboss.as.test.integration.ejb.security.Authentication\* -Delytron
...
Failed tests: 
  AuthenticationElytronTestCase.testAuthenticatedCall:15->AbstractAuthenticationTestCase.testAuthenticatedCall:206 expected:<[user1]> but was:<[anonymous]>
  AuthenticationElytronTestCase.testAuthentication:15->AbstractAuthenticationTestCase.testAuthentication:136 expected:<[user1]> but was:<[anonymous]>
  AuthenticationElytronTestCase.testAuthentication_BadPwd:15->AbstractAuthenticationTestCase.testAuthentication_BadPwd:148 Expected EJBAccessException due to bad password not thrown. (EJB 3.1 FR 17.6.9)
  AuthenticationElytronTestCase.testAuthentication_TwoBeans:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans:161 expected:<[user1]> but was:<[anonymous]>
  AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth:174 expected:<[user1]> but was:<[anonymous]>
  AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth_BadPwd:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_BadPwd:188 Expected EJBAccessException due to bad password not thrown. (EJB 3.1 FR 17.6.9)
  AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:262 null
  AuthenticationElytronTestCase.testICIRSingle:15->AbstractAuthenticationTestCase.testICIRSingle:275 null
  AuthenticationElytronTestCase.testICIR_TwoBeans:15->AbstractAuthenticationTestCase.testICIR_TwoBeans:290 null
  AuthenticationElytronTestCase.testICIR_TwoBeans_ReAuth:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth:312 null
  AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:262 null
Tests in error: 
  AuthenticationElytronTestCase.testAuthentication_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:240->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:252->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testAuthentication_TwoBeans_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:246->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testAuthentication_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_ViaServlet:234->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testICIR_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_ReAuth_ViaServlet:417->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:437->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testICIR_TwoBeans_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ViaServlet:427->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationElytronTestCase.testICIR_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_ViaServlet:407->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:240->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:252->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:246->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testAuthentication_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_ViaServlet:234->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testICIR_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_ReAuth_ViaServlet:417->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:437->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testICIR_TwoBeans_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_TwoBeans_ViaServlet:427->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
  AuthenticationTestCase.testICIR_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_ViaServlet:407->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO

Tests run: 38, Failures: 11, Errors: 16, Skipped: 0
{noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 02:24:01 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 28 Feb 2017 02:24:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8255) New EJB Authentication tests
 (in AS TS) fail with Elytron profile
In-Reply-To: <JIRA.12679129.1488266614000@Atlassian.JIRA>
References: <JIRA.12679129.1488266614000@Atlassian.JIRA>
	<JIRA.12679129.1488266614000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679129.1488266614000.8629.1488266641576@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-8255:
---------------------------------

    Assignee: Jan Kalina  (was: Darran Lofthouse)


> New EJB Authentication tests (in AS TS) fail with Elytron profile
> -----------------------------------------------------------------
>
>                 Key: WFLY-8255
>                 URL: https://issues.jboss.org/browse/WFLY-8255
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Test Suite
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Critical
>
> The newly introduced authentication tests ({{AuthenticationElytronTestCase}}, {{AuthenticationTestCase}}) in {{org.jboss.as.test.integration.ejb.security}} package fail when executed with Elytron AS TS profile.
> {noformat}
> cd testsuite/integration/basic
> mvn clean test -Dtest=org.jboss.as.test.integration.ejb.security.Authentication\* -Delytron
> ...
> Failed tests: 
>   AuthenticationElytronTestCase.testAuthenticatedCall:15->AbstractAuthenticationTestCase.testAuthenticatedCall:206 expected:<[user1]> but was:<[anonymous]>
>   AuthenticationElytronTestCase.testAuthentication:15->AbstractAuthenticationTestCase.testAuthentication:136 expected:<[user1]> but was:<[anonymous]>
>   AuthenticationElytronTestCase.testAuthentication_BadPwd:15->AbstractAuthenticationTestCase.testAuthentication_BadPwd:148 Expected EJBAccessException due to bad password not thrown. (EJB 3.1 FR 17.6.9)
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans:161 expected:<[user1]> but was:<[anonymous]>
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth:174 expected:<[user1]> but was:<[anonymous]>
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth_BadPwd:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_BadPwd:188 Expected EJBAccessException due to bad password not thrown. (EJB 3.1 FR 17.6.9)
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:262 null
>   AuthenticationElytronTestCase.testICIRSingle:15->AbstractAuthenticationTestCase.testICIRSingle:275 null
>   AuthenticationElytronTestCase.testICIR_TwoBeans:15->AbstractAuthenticationTestCase.testICIR_TwoBeans:290 null
>   AuthenticationElytronTestCase.testICIR_TwoBeans_ReAuth:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth:312 null
>   AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth__BadPwd_ViaServlet:262 null
> Tests in error: 
>   AuthenticationElytronTestCase.testAuthentication_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:240->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:252->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testAuthentication_TwoBeans_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:246->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testAuthentication_ViaServlet:15->AbstractAuthenticationTestCase.testAuthentication_ViaServlet:234->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testICIR_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_ReAuth_ViaServlet:417->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:437->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testICIR_TwoBeans_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_TwoBeans_ViaServlet:427->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationElytronTestCase.testICIR_ViaServlet:15->AbstractAuthenticationTestCase.testICIR_ViaServlet:407->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_ReAuth_ViaServlet:240->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ReAuth_ViaServlet:252->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_TwoBeans_ViaServlet:246->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testAuthentication_ViaServlet:11->AbstractAuthenticationTestCase.testAuthentication_ViaServlet:234->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testICIR_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_ReAuth_ViaServlet:417->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_TwoBeans_ReAuth_ViaServlet:437->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testICIR_TwoBeans_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_TwoBeans_ViaServlet:427->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
>   AuthenticationTestCase.testICIR_ViaServlet:11->AbstractAuthenticationTestCase.testICIR_ViaServlet:407->AbstractAuthenticationTestCase.getWhoAmI:359->AbstractAuthenticationTestCase.get:377->AbstractAuthenticationTestCase.execute:393 ? IO
> Tests run: 38, Failures: 11, Errors: 16, Skipped: 0
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 02:34:00 2017
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 28 Feb 2017 02:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8238) Unable to undefine
	credential-reference
In-Reply-To: <JIRA.12678852.1487968505000@Atlassian.JIRA>
References: <JIRA.12678852.1487968505000@Atlassian.JIRA>
	<JIRA.12678852.1487968505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678852.1487968505000.8773.1488267240361@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370030#comment-13370030 ] 

Martin Choma commented on WFLY-8238:
------------------------------------

[~thofman], thank you :)

> 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  Tue Feb 28 02:39:01 2017
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 28 Feb 2017 02:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2159) Delta view cannot be installed
In-Reply-To: <JIRA.12678470.1487846329000@Atlassian.JIRA>
References: <JIRA.12678470.1487846329000@Atlassian.JIRA>
	<JIRA.12678470.1487846329000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678470.1487846329000.8815.1488267541115@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370032#comment-13370032 ] 

Bela Ban commented on JGRP-2159:
--------------------------------

Unit test now reproduces the issue.
Reusing {{Event.GET_CURRENT_VIEW}} to ask the sender of an incompatible delta view for a full view.

> 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  Tue Feb 28 02:59:00 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 02:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.8963.1488268740328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reopened WFCORE-1958:
--------------------------------


Reopening after speaking to Brian, there is one remaining affected test

> 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.Beta6
>
>
> 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  Tue Feb 28 03:55:00 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 28 Feb 2017 03:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7888) Some tests using TimeoutUtil
 fail with security manager
In-Reply-To: <JIRA.12671398.1484576931000@Atlassian.JIRA>
References: <JIRA.12671398.1484576931000@Atlassian.JIRA>
	<JIRA.12671398.1484576931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671398.1484576931000.9387.1488272100323@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka reassigned WFLY-7888:
-------------------------------------

    Assignee: Ondra Chaloupka  (was: Ingo Weiss)


> Some tests using TimeoutUtil fail with security manager
> -------------------------------------------------------
>
>                 Key: WFLY-7888
>                 URL: https://issues.jboss.org/browse/WFLY-7888
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ondra Chaloupka
>
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateless*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateless*
> {{./integration-tests.sh -DtestLogToFile -Dts.noSmoke -Dts.iiop -Dtest=IIOPTimeoutTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (p: default-threadpool; w: Idle) WFLYEJB0034: EJB Invocation failed on component StatelessBean for method public abstract void org.jboss.as.test.iiop.transaction.timeout.TestBeanRemote.testTransaction() throws java.rmi.RemoteException: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	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.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:328)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141)
> 	at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:130)
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.iiop.transaction.timeout.StatelessBean.testTransaction(StatelessBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 54 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/stateless-iiop-txn-timeout.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.stateless-iiop-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:443)
> 	at java.lang.System.getProperty(System.java:427)
> 	at java.lang.Integer.getInteger(Integer.java:1113)
> 	at java.lang.Integer.getInteger(Integer.java:1069)
> 	at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> 	... 81 more
> {code}
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXACommit*
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXARollback*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XaDataSourcePoolStatisticsTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-5) WFLYEJB0034: EJB Invocation failed on component SLSB1 for method public abstract void org.jboss.as.test.integration.jca.statistics.xa.SLSB.commit() throws java.lang.Exception: javax.ejb.EJBException: WFLYEJB0443: EJB 3.1 FR 13.3.3: BMT bean SLSB1 should complete transaction before returning.
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:86)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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.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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
> 	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
> 	... 62 more
> Caused by: java.lang.ExceptionInInitializerError
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.integration.jca.statistics.xa.SLSB1.commit(SLSB1.java:54)
> 	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)
> 	... 60 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/xa-datasource-pool-statistics-test.ear/xa_transactions.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xa-datasource-pool-statistics-test.ear.xa_transactions.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.<clinit>(TimeoutUtil.java:39)
> 	... 78 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 03:56:01 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 28 Feb 2017 03:56:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7888) Some tests using TimeoutUtil
 fail with security manager
In-Reply-To: <JIRA.12671398.1484576931000@Atlassian.JIRA>
References: <JIRA.12671398.1484576931000@Atlassian.JIRA>
	<JIRA.12671398.1484576931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671398.1484576931000.9398.1488272161070@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370083#comment-13370083 ] 

Ondra Chaloupka commented on WFLY-7888:
---------------------------------------

agreed with [~iweiss] to look at this as I wrote the original tests. I will follow Brian's recommendations at PR https://github.com/wildfly/wildfly/pull/9591 to fix the issue

> Some tests using TimeoutUtil fail with security manager
> -------------------------------------------------------
>
>                 Key: WFLY-7888
>                 URL: https://issues.jboss.org/browse/WFLY-7888
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ondra Chaloupka
>
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateless*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateless*
> {{./integration-tests.sh -DtestLogToFile -Dts.noSmoke -Dts.iiop -Dtest=IIOPTimeoutTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (p: default-threadpool; w: Idle) WFLYEJB0034: EJB Invocation failed on component StatelessBean for method public abstract void org.jboss.as.test.iiop.transaction.timeout.TestBeanRemote.testTransaction() throws java.rmi.RemoteException: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	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.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:328)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141)
> 	at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:130)
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.iiop.transaction.timeout.StatelessBean.testTransaction(StatelessBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 54 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/stateless-iiop-txn-timeout.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.stateless-iiop-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:443)
> 	at java.lang.System.getProperty(System.java:427)
> 	at java.lang.Integer.getInteger(Integer.java:1113)
> 	at java.lang.Integer.getInteger(Integer.java:1069)
> 	at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> 	... 81 more
> {code}
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXACommit*
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXARollback*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XaDataSourcePoolStatisticsTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-5) WFLYEJB0034: EJB Invocation failed on component SLSB1 for method public abstract void org.jboss.as.test.integration.jca.statistics.xa.SLSB.commit() throws java.lang.Exception: javax.ejb.EJBException: WFLYEJB0443: EJB 3.1 FR 13.3.3: BMT bean SLSB1 should complete transaction before returning.
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:86)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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.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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
> 	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
> 	... 62 more
> Caused by: java.lang.ExceptionInInitializerError
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.integration.jca.statistics.xa.SLSB1.commit(SLSB1.java:54)
> 	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)
> 	... 60 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/xa-datasource-pool-statistics-test.ear/xa_transactions.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xa-datasource-pool-statistics-test.ear.xa_transactions.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.<clinit>(TimeoutUtil.java:39)
> 	... 78 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 04:13:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 28 Feb 2017 04:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1452) Upgrade maven from 3.2.5 to
	3.3.9
In-Reply-To: <JIRA.12679141.1488273161000@Atlassian.JIRA>
References: <JIRA.12679141.1488273161000@Atlassian.JIRA>
	<JIRA.12679141.1488273161552@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679141.1488273161000.9512.1488273180394@Atlassian.JIRA>

Petr ?irok? created DROOLS-1452:
-----------------------------------

             Summary: Upgrade maven from 3.2.5 to 3.3.9
                 Key: DROOLS-1452
                 URL: https://issues.jboss.org/browse/DROOLS-1452
             Project: Drools
          Issue Type: Task
    Affects Versions: 7.0.0.Beta6
            Reporter: Petr ?irok?
            Assignee: Edson Tirelli


{{kie-ci}} currently depends on Maven 3.2.5 which is quite old. We should try to upgrade to the latest version, 3.3.9.

This will not be as easy as bumping the versions. The {{kie-ci}} maven integration is using manual DI wiring for OSGi (since the default Guice wiring was not working there). It would be worth trying if the Guice now works in OSGi, so that would could avoid the manual wiring which makes the maven upgrades very painful.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 04:13:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 28 Feb 2017 04:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1452) Upgrade maven from 3.2.5 to
	3.3.9
In-Reply-To: <JIRA.12679141.1488273162000@Atlassian.JIRA>
References: <JIRA.12679141.1488273162000@Atlassian.JIRA>
	<JIRA.12679141.1488273162000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679141.1488273162000.9514.1488273180471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1452:
-----------------------------------

    Assignee: Petr ?irok?  (was: Edson Tirelli)


> Upgrade maven from 3.2.5 to 3.3.9
> ---------------------------------
>
>                 Key: DROOLS-1452
>                 URL: https://issues.jboss.org/browse/DROOLS-1452
>             Project: Drools
>          Issue Type: Task
>    Affects Versions: 7.0.0.Beta6
>            Reporter: Petr ?irok?
>            Assignee: Petr ?irok?
>
> {{kie-ci}} currently depends on Maven 3.2.5 which is quite old. We should try to upgrade to the latest version, 3.3.9.
> This will not be as easy as bumping the versions. The {{kie-ci}} maven integration is using manual DI wiring for OSGi (since the default Guice wiring was not working there). It would be worth trying if the Guice now works in OSGi, so that would could avoid the manual wiring which makes the maven upgrades very painful.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 04:49:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 28 Feb 2017 04:49:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.9842.1488275341131@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reopened WFLY-7843:
------------------------------


> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 05:27:00 2017
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 28 Feb 2017 05:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8256) Default value of
 check-for-live-server on master in replication-colocated HA topology should
 be true
In-Reply-To: <JIRA.12679164.1488277537000@Atlassian.JIRA>
References: <JIRA.12679164.1488277537000@Atlassian.JIRA>
	<JIRA.12679164.1488277537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679164.1488277537000.10117.1488277620524@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil moved JBEAP-9178 to WFLY-8256:
------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8256  (was: JBEAP-9178)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JMS
                           (was: ActiveMQ)
    Affects Version/s:     (was: 7.1.0.GA)


> Default value of check-for-live-server on master in replication-colocated HA topology should be true
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8256
>                 URL: https://issues.jboss.org/browse/WFLY-8256
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Critical
>
> check-for-live-server attribute should be set on  true by default, otherwise failback will not work by default and lots of  this messages will spam logs on both servers :
> 15:01:32,379 WARN  [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=4b420277-91ea-11e5-ba47-5d09590e6c44
> Note: changing this value is not possible on ER1 because of https://issues.jboss.org/browse/JBEAP-1980. But with DR12 it works.
>  



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2317) Nested attributes are not
	validated
In-Reply-To: <JIRA.12678336.1487775792000@Atlassian.JIRA>
References: <JIRA.12678336.1487775792000@Atlassian.JIRA>
	<JIRA.12678336.1487775792000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678336.1487775792000.10462.1488280443184@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:03 -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: <JIRA.12677290.1487258960000@Atlassian.JIRA>
References: <JIRA.12677290.1487258960000@Atlassian.JIRA>
	<JIRA.12677290.1487258960000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677290.1487258960000.10469.1488280443366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2302:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2267) Delete all legacy code from
 CallbackHandlerService and SubjectSupplemental implementations
In-Reply-To: <JIRA.12674971.1486314005000@Atlassian.JIRA>
References: <JIRA.12674971.1486314005000@Atlassian.JIRA>
	<JIRA.12674971.1486314005000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674971.1486314005000.10480.1488280443656@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> Only the Elytron realms are now used.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.10493.1488280444025@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2217:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Beta7, 4.0.0.Beta1
>
>
> 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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -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: <JIRA.12662836.1479743300000@Atlassian.JIRA>
References: <JIRA.12662836.1479743300000@Atlassian.JIRA>
	<JIRA.12662836.1479743300000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662836.1479743300000.10507.1488280444353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2163:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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}
> <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS">
>     <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/>
>     <socket-binding http="management-http" https="management-https"/>
> </http-interface>
> {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 Feb 28 06:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2245) credential-reference
 capability-reference constraint
In-Reply-To: <JIRA.12673754.1485800228000@Atlassian.JIRA>
References: <JIRA.12673754.1485800228000@Atlassian.JIRA>
	<JIRA.12673754.1485800228000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673754.1485800228000.10489.1488280443902@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2245:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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 Feb 28 06:14:03 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2301) Mount point not found
 exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
In-Reply-To: <JIRA.12677075.1487199746000@Atlassian.JIRA>
References: <JIRA.12677075.1487199746000@Atlassian.JIRA>
	<JIRA.12677075.1487199746000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677075.1487199746000.10473.1488280443486@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2301:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {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.Beta7, 2.2.1.Final
>
>
> 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.<init>(UnixFileStore.java:65)
>          at sun.nio.fs.LinuxFileStore.<init>(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  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron
	1.1.0.Beta20
In-Reply-To: <JIRA.12671759.1484734661000@Atlassian.JIRA>
References: <JIRA.12671759.1484734661000@Atlassian.JIRA>
	<JIRA.12671759.1484734661000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671759.1484734661000.10500.1488280444214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2206:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -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: <JIRA.12666705.1481282688000@Atlassian.JIRA>
References: <JIRA.12666705.1481282688000@Atlassian.JIRA>
	<JIRA.12666705.1481282688000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666705.1481282688000.10524.1488280444740@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron
	1.1.0.Final
In-Reply-To: <JIRA.12666683.1481279343000@Atlassian.JIRA>
References: <JIRA.12666683.1481279343000@Atlassian.JIRA>
	<JIRA.12666683.1481279343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666683.1481279343000.10531.1488280444918@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:04 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2136) Using management CLI with
 client configuration still prompts for username/password
In-Reply-To: <JIRA.12668500.1482270747000@Atlassian.JIRA>
References: <JIRA.12668500.1482270747000@Atlassian.JIRA>
	<JIRA.12668500.1482270747000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668500.1482270747000.10517.1488280444591@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2071) Properly handle unknown
 roles instead of throwing exception
In-Reply-To: <JIRA.12664620.1480533804000@Atlassian.JIRA>
References: <JIRA.12664620.1480533804000@Atlassian.JIRA>
	<JIRA.12664620.1480533804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664620.1480533804000.10540.1488280445181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2071:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> When mapping roles directly from the identity:
> {code}
> <access-control provider="rbac" use-identity-roles="true"/>
> {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  Tue Feb 28 06:14:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2068)
 HTTPSConnectionWithCLITestCase and HTTPSManagementInterfaceTestCase Failing
 Due To Native Protocol Issue
In-Reply-To: <JIRA.12664603.1480529803000@Atlassian.JIRA>
References: <JIRA.12664603.1480529803000@Atlassian.JIRA>
	<JIRA.12664603.1480529803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12664603.1480529803000.10547.1488280445358@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2046) KeyManager synchronization
 issue when using IBM JDK
In-Reply-To: <JIRA.12663846.1480087207000@Atlassian.JIRA>
References: <JIRA.12663846.1480087207000@Atlassian.JIRA>
	<JIRA.12663846.1480087207000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663846.1480087207000.10555.1488280445629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-2046:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>         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  Tue Feb 28 06:14:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:05 -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: <JIRA.12662507.1479486086000@Atlassian.JIRA>
References: <JIRA.12662507.1479486086000@Atlassian.JIRA>
	<JIRA.12662507.1479486086000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12662507.1479486086000.10563.1488280445853@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:05 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1965) Remove the
 jboss-logging-annotations dependency from the core feature pack.
In-Reply-To: <JIRA.12660292.1478636891000@Atlassian.JIRA>
References: <JIRA.12660292.1478636891000@Atlassian.JIRA>
	<JIRA.12660292.1478636891000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660292.1478636891000.10566.1488280445915@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1965:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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: Darran Lofthouse
>            Priority: Critical
>             Fix For: 3.0.0.Beta7
>
>
> This was added inadvertently with some other changes: -
> {noformat}
>         <dependency>
>             <groupId>org.jboss.logging</groupId>
>             <artifactId>jboss-logging-annotations</artifactId>
>         </dependency>
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:06 -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: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.10570.1488280446047@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>         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<String, String>, 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  Tue Feb 28 06:14:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:06 -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: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.10584.1488280446499@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider
 registration with Elytron
In-Reply-To: <JIRA.12650406.1473990565000@Atlassian.JIRA>
References: <JIRA.12650406.1473990565000@Atlassian.JIRA>
	<JIRA.12650406.1473990565000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12650406.1473990565000.10598.1488280446888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1802:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1897) Follow up WFCORE-296 once
 migrated to Remoting 5
In-Reply-To: <JIRA.12657047.1477476025000@Atlassian.JIRA>
References: <JIRA.12657047.1477476025000@Atlassian.JIRA>
	<JIRA.12657047.1477476025000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12657047.1477476025000.10590.1488280446674@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:06 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.10577.1488280446204@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1958:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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  Tue Feb 28 06:14:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:07 -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: <JIRA.12633460.1466166240000@Atlassian.JIRA>
References: <JIRA.12633460.1466166240000@Atlassian.JIRA>
	<JIRA.12633460.1466166240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633460.1466166240000.10612.1488280447278@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:07 -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: <JIRA.12626950.1463652179000@Atlassian.JIRA>
References: <JIRA.12626950.1463652179000@Atlassian.JIRA>
	<JIRA.12626950.1463652179000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12626950.1463652179000.10616.1488280447417@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>         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  Tue Feb 28 06:14:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:07 -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: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.10603.1488280447051@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:07 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:07 -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: <JIRA.12599313.1452694761000@Atlassian.JIRA>
References: <JIRA.12599313.1452694761000@Atlassian.JIRA>
	<JIRA.12599313.1452694761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599313.1452694761000.10627.1488280447867@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-1351:
-------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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: David Lloyd
>            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  Tue Feb 28 06:14:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1059)
 RestartParentResourceAdd/RemoveHandler should handle capability
 registration
In-Reply-To: <JIRA.12589111.1444833283000@Atlassian.JIRA>
References: <JIRA.12589111.1444833283000@Atlassian.JIRA>
	<JIRA.12589111.1444833283000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12589111.1444833283000.10646.1488280448301@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1145) Review of HostController /
 Application Server Remoting connections
In-Reply-To: <JIRA.12593602.1448020143000@Atlassian.JIRA>
References: <JIRA.12593602.1448020143000@Atlassian.JIRA>
	<JIRA.12593602.1448020143000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12593602.1448020143000.10642.1488280448206@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-644) jboss-cli needs to support
 using PKCS11 (including FIPS mode) keystores/truststores
In-Reply-To: <JIRA.12568653.1429218385000@Atlassian.JIRA>
References: <JIRA.12568653.1429218385000@Atlassian.JIRA>
	<JIRA.12568653.1429218385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568653.1429218385000.10657.1488280448652@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-644:
------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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.<init>(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  Tue Feb 28 06:14:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-887) "Deprecate" using an
 expression in model refs to interfaces
In-Reply-To: <JIRA.12581612.1439829074000@Atlassian.JIRA>
References: <JIRA.12581612.1439829074000@Atlassian.JIRA>
	<JIRA.12581612.1439829074000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12581612.1439829074000.10650.1488280448426@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> "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.Beta7
>
>
> 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  Tue Feb 28 06:14:08 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:08 -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: <JIRA.12594731.1448952936000@Atlassian.JIRA>
References: <JIRA.12594731.1448952936000@Atlassian.JIRA>
	<JIRA.12594731.1448952936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12594731.1448952936000.10636.1488280448065@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>         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  Tue Feb 28 06:14:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.10663.1488280449223@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-459:
------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Beta7
>
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:09 -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: <JIRA.12472187.1344607033000@Atlassian.JIRA>
References: <JIRA.12472187.1344607033000@Atlassian.JIRA>
	<JIRA.12472187.1344607033000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472187.1344607033000.10667.1488280449375@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 06:14:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.10671.1488280449467@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-266:
------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 3.0.0.Beta7
>
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.10674.1488280449531@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFCORE-107:
------------------------------
    Fix Version/s: 3.0.0.Beta7
                       (was: 3.0.0.Beta6)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta7
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 06:14:09 2017
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 28 Feb 2017 06:14:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-13) End users can call
 non-published management API operations
In-Reply-To: <JIRA.12508718.1382628380000@Atlassian.JIRA>
References: <JIRA.12508718.1382628380000@Atlassian.JIRA>
	<JIRA.12508718.1382628380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508718.1382628380000.10680.1488280449694@Atlassian.JIRA>


     [ 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.Beta7
                       (was: 3.0.0.Beta6)


> 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.Beta7
>
>
> 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  Tue Feb 28 07:07:01 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 28 Feb 2017 07:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.11308.1488283621356@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370245#comment-13370245 ] 

Jan Kalina commented on WFLY-7843:
----------------------------------

??Configured property is parsed also with quotation marks.??
Actually ModelNode (of type STRING) object pushed into environment instead of String.

> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 07:31:00 2017
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 28 Feb 2017 07:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7888) Some tests using TimeoutUtil
 fail with security manager
In-Reply-To: <JIRA.12671398.1484576931000@Atlassian.JIRA>
References: <JIRA.12671398.1484576931000@Atlassian.JIRA>
	<JIRA.12671398.1484576931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12671398.1484576931000.11485.1488285060194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka updated WFLY-7888:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/9591, https://github.com/wildfly/wildfly/pull/9721  (was: https://github.com/wildfly/wildfly/pull/9591)


> Some tests using TimeoutUtil fail with security manager
> -------------------------------------------------------
>
>                 Key: WFLY-7888
>                 URL: https://issues.jboss.org/browse/WFLY-7888
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Jan Tymel
>            Assignee: Ondra Chaloupka
>
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#noTimeoutStateless*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateful*
> *org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase#timeoutStateless*
> {{./integration-tests.sh -DtestLogToFile -Dts.noSmoke -Dts.iiop -Dtest=IIOPTimeoutTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (p: default-threadpool; w: Idle) WFLYEJB0034: EJB Invocation failed on component StatelessBean for method public abstract void org.jboss.as.test.iiop.transaction.timeout.TestBeanRemote.testTransaction() throws java.rmi.RemoteException: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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:44)
> 	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.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$1.processInvocation(EjbExceptionTransformingInterceptorFactories.java:75)
> 	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(AccessController.java:686)
> 	at java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:742)
> 	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.ejb3.iiop.EjbCorbaServant._invoke(EjbCorbaServant.java:328)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:654)
> 	at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:205)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1700)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1558)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:940)
> 	at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:198)
> 	at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:712)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:471)
> 	at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1230)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:490)
> 	at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:519)
> Caused by: java.lang.ExceptionInInitializerError
> 	at java.lang.J9VMInternals.ensureError(J9VMInternals.java:141)
> 	at java.lang.J9VMInternals.recordInitializationFailure(J9VMInternals.java:130)
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.iiop.transaction.timeout.StatelessBean.testTransaction(StatelessBean.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.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.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.invokeInOurTx(CMTTxInterceptor.java:275)
> 	... 54 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/stateless-iiop-txn-timeout.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.stateless-iiop-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:443)
> 	at java.lang.System.getProperty(System.java:427)
> 	at java.lang.Integer.getInteger(Integer.java:1113)
> 	at java.lang.Integer.getInteger(Integer.java:1069)
> 	at org.jboss.as.test.shared.TimeoutUtil.<clinit>(TimeoutUtil.java:39)
> 	... 81 more
> {code}
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXACommit*
> *org.jboss.as.test.integration.jca.statistics.xa.XaDataSourcePoolStatisticsTestCase#testXARollback*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=XaDataSourcePoolStatisticsTestCase -Dsecurity.manager}}
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-5) WFLYEJB0034: EJB Invocation failed on component SLSB1 for method public abstract void org.jboss.as.test.integration.jca.statistics.xa.SLSB.commit() throws java.lang.Exception: javax.ejb.EJBException: WFLYEJB0443: EJB 3.1 FR 13.3.3: BMT bean SLSB1 should complete transaction before returning.
> 	at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:86)
> 	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: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.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	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.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.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:340)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:68)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:268)
> 	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)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:434)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:789)
> 	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
> 	... 62 more
> Caused by: java.lang.ExceptionInInitializerError
> 	at org.jboss.as.test.integration.transactions.TxTestUtil.<clinit>(TxTestUtil.java:42)
> 	at org.jboss.as.test.integration.jca.statistics.xa.SLSB1.commit(SLSB1.java:54)
> 	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)
> 	... 60 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "ts.timeout.factor" "read")" in code source "(vfs:/content/xa-datasource-pool-statistics-test.ear/xa_transactions.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.xa-datasource-pool-statistics-test.ear.xa_transactions.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.<clinit>(TimeoutUtil.java:39)
> 	... 78 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 07:39:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 28 Feb 2017 07:39: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: <JIRA.12679189.1488285489000@Atlassian.JIRA>
References: <JIRA.12679189.1488285489000@Atlassian.JIRA>
	<JIRA.12679189.1488285489320@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679189.1488285489000.11535.1488285540224@Atlassian.JIRA>

Josef Cacek created WFLY-8257:
---------------------------------

             Summary: 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: Bug
          Components: Test Suite
            Reporter: 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  Tue Feb 28 07:39:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 28 Feb 2017 07:39: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: <JIRA.12679189.1488285489000@Atlassian.JIRA>
References: <JIRA.12679189.1488285489000@Atlassian.JIRA>
	<JIRA.12679189.1488285489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679189.1488285489000.11537.1488285540266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek reassigned WFLY-8257:
---------------------------------

    Assignee: Josef Cacek


> 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: Bug
>          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  Tue Feb 28 07:40:00 2017
From: issues at jboss.org (Josef Cacek (JIRA))
Date: Tue, 28 Feb 2017 07:40: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: <JIRA.12679189.1488285489000@Atlassian.JIRA>
References: <JIRA.12679189.1488285489000@Atlassian.JIRA>
	<JIRA.12679189.1488285489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679189.1488285489000.11543.1488285600198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Josef Cacek updated WFLY-8257:
------------------------------
    Issue Type: Task  (was: Bug)


> 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  Tue Feb 28 08:05:00 2017
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 28 Feb 2017 08:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1445) Mask should reflect
 properties accessed in other nodes join constraints
In-Reply-To: <JIRA.12677693.1487579055000@Atlassian.JIRA>
References: <JIRA.12677693.1487579055000@Atlassian.JIRA>
	<JIRA.12677693.1487579055000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677693.1487579055000.11730.1488287100296@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370300#comment-13370300 ] 

Mario Fusco commented on DROOLS-1445:
-------------------------------------

Accumulate test case fixed by https://github.com/droolsjbpm/drools/commit/fa39028c72f46a211f56cc6389a10ca3c3da3d96

> Mask should reflect properties accessed in other nodes join constraints
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1445
>                 URL: https://issues.jboss.org/browse/DROOLS-1445
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>             Fix For: 7.0.0.CR1
>
>
> The following test exhibit a failing and a working test:
> {code:java}
>     @Test()
>     public void testAbis_NotWorking() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "    $p2 : Person( age > $p1.age ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         ksession.addEventListener(new DebugAgendaEventListener());
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
>     
>     @Test()
>     public void testAbis_Working() {
>         // DROOLS-644
>         String drl =
>                 "import " + Person.class.getCanonicalName() + ";\n" +
>                 "global java.util.List list;\n" +
>                 "rule R when\n" +
>                 "    $p1 : Person( name == \"Mario\", $a1: age) \n" +
>                 "    $p2 : Person( age > $a1 ) \n" +
>                 "then\n" +
>                 "    list.add(\"t0\");\n" +
>                 "end\n" +
>                 "rule Z when\n" +
>                 "    $p1 : Person( name == \"Mario\" ) \n" +
>                 "then\n" +
>                 "    modify($p1) { setAge(35); } \n" +
>                 "end\n" 
>                 ;
>         // making the default explicit:
>         KieSession ksession = new KieHelper(PropertySpecificOption.ALWAYS).addContent(drl, ResourceType.DRL)
>                 .build()
>                 .newKieSession();
>         
>         System.out.println(drl);
>         ReteDumper.dumpRete(ksession);
>         List<String> list = new ArrayList<String>();
>         ksession.setGlobal("list", list);
>         Person mario = new Person("Mario", 40);
>         Person mark = new Person("Mark", 37);
>         FactHandle fh_mario = ksession.insert(mario);
>         ksession.insert(mark);
>         int x = ksession.fireAllRules();
>         assertEquals(1, list.size());
>         assertEquals("t0", list.get(0));
>     }
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:06:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 28 Feb 2017 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1453) Property Reactivity ALWAYS
 failing BackwardChainingTest
In-Reply-To: <JIRA.12679202.1488287125000@Atlassian.JIRA>
References: <JIRA.12679202.1488287125000@Atlassian.JIRA>
	<JIRA.12679202.1488287125068@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679202.1488287125000.11746.1488287160370@Atlassian.JIRA>

Matteo Mortari created DROOLS-1453:
--------------------------------------

             Summary: Property Reactivity ALWAYS failing BackwardChainingTest
                 Key: DROOLS-1453
                 URL: https://issues.jboss.org/browse/DROOLS-1453
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Matteo Mortari
            Assignee: Mario Fusco


Property Reactivity ALWAYS is making {{org.drools.compiler.integrationtests.BackwardChainingTest}} fail with the following problems:

{code:java}
org.drools.compiler.integrationtests.BackwardChainingTest
testNaniSearchs(org.drools.compiler.integrationtests.BackwardChainingTest)
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
	at java.util.ArrayList.rangeCheck(ArrayList.java:653)
	at java.util.ArrayList.get(ArrayList.java:429)
	at org.drools.compiler.integrationtests.BackwardChainingTest.testNaniSearchs(BackwardChainingTest.java:1394)
	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.InvokeMethod.evaluate(InvokeMethod.java:17)
	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:678)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

testOpenBackwardChain(org.drools.compiler.integrationtests.BackwardChainingTest)
java.util.NoSuchElementException
	at java.util.LinkedList.removeFirst(LinkedList.java:270)
	at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.createQueryResultHandle(QueryElementNode.java:404)
	at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowAdded(QueryElementNode.java:311)
	at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:82)
	at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:318)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:231)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:174)
	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:213)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:207)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller$PBActivationsFilter.fireRNEAs(ProtobufInputMarshaller.java:831)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:256)
	at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:161)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:113)
	at org.drools.compiler.integrationtests.SerializationHelper.getSerialisedStatefulKnowledgeSession(SerializationHelper.java:95)
	at org.drools.compiler.integrationtests.SerializationHelper.getSerialisedStatefulKnowledgeSession(SerializationHelper.java:61)
	at org.drools.compiler.integrationtests.SerializationHelper.getSerialisedStatefulKnowledgeSession(SerializationHelper.java:52)
	at org.drools.compiler.integrationtests.BackwardChainingTest.testOpenBackwardChain(BackwardChainingTest.java:2108)
	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.InvokeMethod.evaluate(InvokeMethod.java:17)
	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:678)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)


{code}




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:20:00 2017
From: issues at jboss.org (Patrick Reinhart (JIRA))
Date: Tue, 28 Feb 2017 08:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8258) Upgrade to IronJacamar 1.3.5
In-Reply-To: <JIRA.12679204.1488287954000@Atlassian.JIRA>
References: <JIRA.12679204.1488287954000@Atlassian.JIRA>
	<JIRA.12679204.1488287954490@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679204.1488287954000.11843.1488288000249@Atlassian.JIRA>

Patrick Reinhart created WFLY-8258:
--------------------------------------

             Summary: Upgrade to IronJacamar 1.3.5
                 Key: WFLY-8258
                 URL: https://issues.jboss.org/browse/WFLY-8258
             Project: WildFly
          Issue Type: Component Upgrade
          Components: JCA
    Affects Versions: 10.1.0.Final
            Reporter: Patrick Reinhart
            Assignee: Stefano Maestri


Statement.cancel() is not invoked until the statement is completed



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:29:00 2017
From: issues at jboss.org (Oleg Kozakevych (JIRA))
Date: Tue, 28 Feb 2017 08:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7823) AMQP remote client failed to
	connect
In-Reply-To: <JIRA.12668415.1482247594000@Atlassian.JIRA>
References: <JIRA.12668415.1482247594000@Atlassian.JIRA>
	<JIRA.12668415.1482247594000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12668415.1482247594000.11884.1488288540167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370318#comment-13370318 ] 

Oleg Kozakevych commented on WFLY-7823:
---------------------------------------

It seems that it is not enough to update proton-j. I tried to do it and outcome is still the same.
1. What means "proton-jms seems not need"? Have you removed it at all?
2. Could you please write more detailed instruction what you changed to make it working?
3. Do you have some other modules customized in WildFly?
4. Which version of WildFly did you use?
5. What exactly "simple amqp remote client" did you use?

> 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 <WFLY_HOME>/modules/system/layers/base/org/apache/activemq/artemis/protocol/amqp/main) needs a dependency on Netty in its module.xml (e.g. <module name="io.netty"/>).
> 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 <WFLY_HOME>/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  Tue Feb 28 08:34:01 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 28 Feb 2017 08:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1450) Validation rule
 ITEMDEF_NOT_UNIQUE not allowing two structure with same attributes
In-Reply-To: <JIRA.12678740.1487933946000@Atlassian.JIRA>
References: <JIRA.12678740.1487933946000@Atlassian.JIRA>
	<JIRA.12678740.1487933946000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678740.1487933946000.11919.1488288841029@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-1450:
-----------------------------------
    Component/s: dmn engine


> Validation rule ITEMDEF_NOT_UNIQUE not allowing two structure with same attributes
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-1450
>                 URL: https://issues.jboss.org/browse/DROOLS-1450
>             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  Tue Feb 28 08:35:00 2017
From: issues at jboss.org (Stefano Maestri (JIRA))
Date: Tue, 28 Feb 2017 08:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8259) CLI Batch mode doesn't do
 roll back correctly during adding of distributed-workmanager of JCA
In-Reply-To: <JIRA.12679209.1488288831000@Atlassian.JIRA>
References: <JIRA.12679209.1488288831000@Atlassian.JIRA>
	<JIRA.12679209.1488288831000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679209.1488288831000.11927.1488288900629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri moved JBEAP-9186 to WFLY-8259:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-8259  (was: JBEAP-9186)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                           (was: JCA)
    Affects Version/s:     (was: 7.1.0.DR11)


> CLI Batch mode doesn't do roll back correctly during adding of distributed-workmanager of JCA
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8259
>                 URL: https://issues.jboss.org/browse/WFLY-8259
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>
> CLI Batch mode doesn't do roll back correctly during adding of distributed-workmanager of JCA
> *Steps to reproduce:*
> # ./standalone.sh  -c standalone-ha.xml
> # ./jboss-cli.sh -c
> # # batch
> # /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
> # /subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwaaaaaaaaaa:add(queue-length=20,max-threads=20)
> # run-batch
> # # error is printed, correct, management commands were wrong
> # list-batch
> # discard-batch
> # batch
> # list-batch
> # /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
> # /subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwm:add(queue-length=20,max-threads=20)
> # list-batch
> # run-batch
> # # error is printed, wrong, because management commands are correct. Previous batch command probably doesn't do roll back correctly
> # discard-batch
> # reload
> # batch
> # /subsystem=jca/distributed-workmanager=newdwm:add(name=newdwm)
> # /subsystem=jca/distributed-workmanager=newdwm/short-running-threads=newdwm:add(queue-length=20,max-threads=20)
> # run-batch
> # # works correctly, but only after reload



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:35:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 28 Feb 2017 08:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.11940.1488288900925@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370324#comment-13370324 ] 

Hayk Hovsepyan commented on HAWKULARQE-41:
------------------------------------------

Smoke tests are finished, no regression was found https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20-%20EAP%207-1%20Server%20Smoke%20Tests

> Hawkular Agent for EAP7.1
> -------------------------
>
>                 Key: HAWKULARQE-41
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:36:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 28 Feb 2017 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1454) OSGify the kie-dmn modules
In-Reply-To: <JIRA.12679210.1488288911000@Atlassian.JIRA>
References: <JIRA.12679210.1488288911000@Atlassian.JIRA>
	<JIRA.12679210.1488288911121@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679210.1488288911000.11942.1488288960280@Atlassian.JIRA>

Matteo Mortari created DROOLS-1454:
--------------------------------------

             Summary: OSGify the kie-dmn modules
                 Key: DROOLS-1454
                 URL: https://issues.jboss.org/browse/DROOLS-1454
             Project: Drools
          Issue Type: Feature Request
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:36:00 2017
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Tue, 28 Feb 2017 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-41) Hawkular Agent for EAP7.1
In-Reply-To: <JIRA.12677339.1487270138000@Atlassian.JIRA>
References: <JIRA.12677339.1487270138000@Atlassian.JIRA>
	<JIRA.12677339.1487270138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12677339.1487270138000.11953.1488288960571@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hayk Hovsepyan resolved HAWKULARQE-41.
--------------------------------------
    Resolution: Done


Hawkular Agent is EAP 7.1 compatible, testing is done on EAP 7.1 DR12

> Hawkular Agent for EAP7.1
> -------------------------
>
>                 Key: HAWKULARQE-41
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-41
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>
> Smoke test is required based on template https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testrun?id=CFME%20%2D%20EAP7%20Server%20Smoke%20Tests%20Template



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:36:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 28 Feb 2017 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1454) OSGify the kie-dmn modules
In-Reply-To: <JIRA.12679210.1488288911000@Atlassian.JIRA>
References: <JIRA.12679210.1488288911000@Atlassian.JIRA>
	<JIRA.12679210.1488288911000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679210.1488288911000.11956.1488288960751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-1454:
-----------------------------------
    Component/s: dmn engine


> OSGify 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: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:37:00 2017
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 28 Feb 2017 08:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1454) OSGi -fy the kie-dmn modules
In-Reply-To: <JIRA.12679210.1488288911000@Atlassian.JIRA>
References: <JIRA.12679210.1488288911000@Atlassian.JIRA>
	<JIRA.12679210.1488288911000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679210.1488288911000.11961.1488289020212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-1454:
-----------------------------------
    Summary: OSGi -fy the kie-dmn modules  (was: OSGify the kie-dmn modules)


> 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: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:43:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 28 Feb 2017 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7843) Initial context factory is
 not able to be set in Elytron dir-context
In-Reply-To: <JIRA.12669000.1483356681000@Atlassian.JIRA>
References: <JIRA.12669000.1483356681000@Atlassian.JIRA>
	<JIRA.12669000.1483356681000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669000.1483356681000.11996.1488289380270@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7843:
-----------------------------
    Fix Version/s: 11.0.0.Alpha1


> Initial context factory is not able to be set in Elytron dir-context
> --------------------------------------------------------------------
>
>                 Key: WFLY-7843
>                 URL: https://issues.jboss.org/browse/WFLY-7843
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem does not allow to configure custom Initial context factory for dir-context. 
> Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 08:54:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 08:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2340) Expose the management
 executor via a capability
In-Reply-To: <JIRA.12679213.1488289980000@Atlassian.JIRA>
References: <JIRA.12679213.1488289980000@Atlassian.JIRA>
	<JIRA.12679213.1488289980623@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679213.1488289980000.12035.1488290040390@Atlassian.JIRA>

Brian Stansberry created WFCORE-2340:
----------------------------------------

             Summary: 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


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  Tue Feb 28 09:00:01 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 28 Feb 2017 09:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2341) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12679214.1488290341000@Atlassian.JIRA>
References: <JIRA.12679214.1488290341000@Atlassian.JIRA>
	<JIRA.12679214.1488290341000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679214.1488290341000.12142.1488290401281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga moved WFLY-8260 to WFCORE-2341:
--------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2341  (was: WFLY-8260)
     Issue Type: Bug  (was: Task)
    Component/s: Security
                     (was: Security)


> ldap role should ignore javax.naming.PartialResultException when referrals=ignore
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2341
>                 URL: https://issues.jboss.org/browse/WFCORE-2341
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 
> ldap role should ignore javax.naming.PartialResultException when referrals=ignore.
> In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
> {code}
> 15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
> 15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
> 	ref 1: 'AGENTS.AMFAM.NET'
> \00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
> 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
> 	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
> 	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
> 	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
> 	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> 	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> 	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> 	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> {code}
> Setting referrals=follows worked around the issue in this case.
> Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 09:00:00 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 28 Feb 2017 09:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8260) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12679214.1488290340000@Atlassian.JIRA>
References: <JIRA.12679214.1488290340000@Atlassian.JIRA>
	<JIRA.12679214.1488290340942@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679214.1488290340000.12131.1488290400952@Atlassian.JIRA>

Peter Palaga created WFLY-8260:
----------------------------------

             Summary: ldap role should ignore javax.naming.PartialResultException when referrals=ignore
                 Key: WFLY-8260
                 URL: https://issues.jboss.org/browse/WFLY-8260
             Project: WildFly
          Issue Type: Task
          Components: Security
            Reporter: Peter Palaga
            Assignee: Peter Palaga


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
	ref 1: 'AGENTS.AMFAM.NET'
\00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 09:06:00 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 28 Feb 2017 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8261) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12679216.1488290701000@Atlassian.JIRA>
References: <JIRA.12679216.1488290701000@Atlassian.JIRA>
	<JIRA.12679216.1488290701780@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679216.1488290701000.12244.1488290760466@Atlassian.JIRA>

Peter Palaga created WFLY-8261:
----------------------------------

             Summary: ldap role should ignore javax.naming.PartialResultException when referrals=ignore
                 Key: WFLY-8261
                 URL: https://issues.jboss.org/browse/WFLY-8261
             Project: WildFly
          Issue Type: Task
          Components: Security
            Reporter: Peter Palaga
            Assignee: Peter Palaga


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
	ref 1: 'AGENTS.AMFAM.NET'
\00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 09:30:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 28 Feb 2017 09:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-173) Need system property to enable
 EL 2.2 backward compatible switch "javax.el.bc2.2"
In-Reply-To: <JIRA.12679223.1488292176000@Atlassian.JIRA>
References: <JIRA.12679223.1488292176000@Atlassian.JIRA>
	<JIRA.12679223.1488292176488@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679223.1488292176000.12476.1488292200439@Atlassian.JIRA>

Ivo Studensky created JBEE-173:
----------------------------------

             Summary: Need system property to enable EL 2.2 backward compatible switch "javax.el.bc2.2"
                 Key: JBEE-173
                 URL: https://issues.jboss.org/browse/JBEE-173
             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: Ivo Studensky
            Assignee: Ivo Studensky


[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. User migration is blocked and needs system property to enable backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 09:31:00 2017
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 28 Feb 2017 09:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7996) Default Elytron subsystem
 configuration doesn't support local authentication in ApplicationRealm
In-Reply-To: <JIRA.12673705.1485788656000@Atlassian.JIRA>
References: <JIRA.12673705.1485788656000@Atlassian.JIRA>
	<JIRA.12673705.1485788656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673705.1485788656000.12487.1488292260521@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reopened WFLY-7996:
------------------------------


> Default Elytron subsystem configuration doesn't support local authentication in ApplicationRealm
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7996
>                 URL: https://issues.jboss.org/browse/WFLY-7996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 11.0.0.Alpha1
>
>
> 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  Tue Feb 28 09:38:00 2017
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 28 Feb 2017 09:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6755) mod_cluster uses the same
 password for accessing sslKeyStore and sslTrustStore
In-Reply-To: <JIRA.12467173.1337788451000@Atlassian.JIRA>
References: <JIRA.12467173.1337788451000@Atlassian.JIRA>
	<JIRA.12467173.1337788451000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467173.1337788451000.12552.1488292680982@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-6755.
--------------------------------
    Fix Version/s:     (was: 11.0.0.Alpha1)
       Resolution: Out of Date


With elytron integration in place (WFLY-3884) users should migrate their configuration to use elytron where this is no longer a problem.

> mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-6755
>                 URL: https://issues.jboss.org/browse/WFLY-6755
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> Problem reported by Duncan Doyle.
> The passwords shouldn't be forced to be the same, in AS5 they could have been different.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 09:39:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 28 Feb 2017 09:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis:
 DefaultSingleSignOn.getIdentity() not synchronized
In-Reply-To: <JIRA.12672942.1485334161000@Atlassian.JIRA>
References: <JIRA.12672942.1485334161000@Atlassian.JIRA>
	<JIRA.12672942.1485334161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672942.1485334161000.12557.1488292740241@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned ELY-957:
--------------------------------

    Assignee: Paul Ferraro  (was: Ilia Vassilev)


> 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  Tue Feb 28 09:40:00 2017
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 28 Feb 2017 09:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-957) Coverity static analysis:
 DefaultSingleSignOn.getIdentity() not synchronized
In-Reply-To: <JIRA.12672942.1485334161000@Atlassian.JIRA>
References: <JIRA.12672942.1485334161000@Atlassian.JIRA>
	<JIRA.12672942.1485334161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672942.1485334161000.12562.1488292800295@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370388#comment-13370388 ] 

Paul Ferraro commented on ELY-957:
----------------------------------

There's no reason to synchronize this method. If the synchronized modifier in the method signature of DefaultSingleSignOn.setIdentity(...) is cumbersome for subclasses, then there are better ways to address this (e.g. by replacing the modifier with a synchronized block, and clarifying the javadoc).

> 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  Tue Feb 28 10:10:01 2017
From: issues at jboss.org (=?UTF-8?Q?M=C3=A9lanie_Gauthier_=28JIRA=29?=)
Date: Tue, 28 Feb 2017 10:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1455) ClassCastException when
 using yearMonthDuration in decision table
In-Reply-To: <JIRA.12679310.1488294598000@Atlassian.JIRA>
References: <JIRA.12679310.1488294598000@Atlassian.JIRA>
	<JIRA.12679310.1488294598499@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679310.1488294598000.76.1488294601656@Atlassian.JIRA>

M?lanie Gauthier created DROOLS-1455:
----------------------------------------

             Summary: ClassCastException when using yearMonthDuration in decision table
                 Key: DROOLS-1455
                 URL: https://issues.jboss.org/browse/DROOLS-1455
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: M?lanie Gauthier
            Assignee: Edson Tirelli
         Attachments: yearMonthDuration.dmn

Trying to run the attached example, a ClasCastException error is logged. dayTimeDuration works fine.

A Period object is put in the context, created using 
BuiltInType feelType = (BuiltInType) BuiltInType.determineTypeFromName(type);



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 10:26:05 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 28 Feb 2017 10:26:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8231) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12678727.1487930532000@Atlassian.JIRA>
References: <JIRA.12678727.1487930532000@Atlassian.JIRA>
	<JIRA.12678727.1487930532000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678727.1487930532000.289.1488295565099@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated WFLY-8231:
-------------------------------
    Description: 
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the user has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
16:22:09,407 TRACE [org.jboss.as.domain.management.security] (management task-4) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - REFERRAL: failed for MessageType : SEARCH_REQUEST
Message ID : 4
    SearchRequest
        baseDn : 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
        filter : '(objectClass=*)'
        scope : base object
        typesOnly : false
        Size Limit : no limit
        Time Limit : no limit
        Deref Aliases : deref Always
        attributes : 'cn'
org.apache.directory.api.ldap.model.message.SearchRequestImpl at 7887cbbc    ManageDsaITImpl Control
        Type OID    : '2.16.840.1.113730.3.4.2'
        Criticality : 'false'
'
: ERR_315 cannot create an entry under a referral when the Context.REFERRAL is set to 'ignore']; remaining name 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
        at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:313)
        at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:217)
        at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
        at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1716)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1741)
        at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:470)
        at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:465)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:750)
        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.authorize(UsernamePasswordAuthenticationMechanism.java:92)
        at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
        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.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
        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}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272

  was:
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
	ref 1: 'AGENTS.AMFAM.NET'
\00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



> ldap role should ignore javax.naming.PartialResultException when referrals=ignore
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-8231
>                 URL: https://issues.jboss.org/browse/WFLY-8231
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 
> ldap role should ignore javax.naming.PartialResultException when referrals=ignore.
> In this case, the user has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
> {code}
> 16:22:09,407 TRACE [org.jboss.as.domain.management.security] (management task-4) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - REFERRAL: failed for MessageType : SEARCH_REQUEST
> Message ID : 4
>     SearchRequest
>         baseDn : 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
>         filter : '(objectClass=*)'
>         scope : base object
>         typesOnly : false
>         Size Limit : no limit
>         Time Limit : no limit
>         Deref Aliases : deref Always
>         attributes : 'cn'
> org.apache.directory.api.ldap.model.message.SearchRequestImpl at 7887cbbc    ManageDsaITImpl Control
>         Type OID    : '2.16.840.1.113730.3.4.2'
>         Criticality : 'false'
> '
> : ERR_315 cannot create an entry under a referral when the Context.REFERRAL is set to 'ignore']; remaining name 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
>         at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
>         at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
>         at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
>         at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
>         at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
>         at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
>         at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
>         at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
>         at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:313)
>         at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:217)
>         at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
>         at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1716)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1741)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:470)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:465)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:750)
>         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.authorize(UsernamePasswordAuthenticationMechanism.java:92)
>         at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
>         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.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
>         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}
> Setting referrals=follows worked around the issue in this case.
> Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:26:05 2017
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 28 Feb 2017 10:26:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2341) ldap role should ignore
 javax.naming.PartialResultException when referrals=ignore
In-Reply-To: <JIRA.12679214.1488290341000@Atlassian.JIRA>
References: <JIRA.12679214.1488290341000@Atlassian.JIRA>
	<JIRA.12679214.1488290341000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679214.1488290341000.296.1488295565779@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated WFCORE-2341:
---------------------------------
    Description: 
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the user has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
16:22:09,407 TRACE [org.jboss.as.domain.management.security] (management task-4) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - REFERRAL: failed for MessageType : SEARCH_REQUEST
Message ID : 4
    SearchRequest
        baseDn : 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
        filter : '(objectClass=*)'
        scope : base object
        typesOnly : false
        Size Limit : no limit
        Time Limit : no limit
        Deref Aliases : deref Always
        attributes : 'cn'
org.apache.directory.api.ldap.model.message.SearchRequestImpl at 7887cbbc    ManageDsaITImpl Control
        Type OID    : '2.16.840.1.113730.3.4.2'
        Criticality : 'false'
'
: ERR_315 cannot create an entry under a referral when the Context.REFERRAL is set to 'ignore']; remaining name 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
        at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:313)
        at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:217)
        at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
        at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
        at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1716)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1741)
        at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:470)
        at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:465)
        at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:750)
        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.authorize(UsernamePasswordAuthenticationMechanism.java:92)
        at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
        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.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
        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}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272

  was:
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 

ldap role should ignore javax.naming.PartialResultException when referrals=ignore.

In this case, the customer has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
{code}
15:10:04,355 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Group found with distinguishedName=CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET
15:10:04,357 TRACE [org.jboss.as.domain.management.security] (HttpManagementService-threads - 7) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100742, data 0, 1 access points
	ref 1: 'AGENTS.AMFAM.NET'
\00]; remaining name 'CN=AGENTS-REGISTERED-DS 7431,OU=Automated,OU=Groups,DC=AGENTS,DC=AMFAM,DC=NET'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888) [rt.jar:1.8.0_66]
	at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) [rt.jar:1.8.0_66]
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.8.0_66]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:297) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:215) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:223) [jboss-as-domain-management-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator._authenticate(BasicAuthenticator.java:120) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.security.BasicAuthenticator.authenticate(BasicAuthenticator.java:85) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:64)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
	at org.jboss.as.domain.http.server.XFrameHeaderFilter.doFilter(XFrameHeaderFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:48) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
	at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
	at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:680)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
{code}

Setting referrals=follows worked around the issue in this case.

Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



> ldap role should ignore javax.naming.PartialResultException when referrals=ignore
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2341
>                 URL: https://issues.jboss.org/browse/WFCORE-2341
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1418685 
> ldap role should ignore javax.naming.PartialResultException when referrals=ignore.
> In this case, the user has a role which is causing a referral.  They have referrals=ignore which causes a PartialResultException to be logged.  This ends up causing a 500 error.
> {code}
> 16:22:09,407 TRACE [org.jboss.as.domain.management.security] (management task-4) Failure supplementing Subject: javax.naming.PartialResultException: [LDAP: error code 10 - REFERRAL: failed for MessageType : SEARCH_REQUEST
> Message ID : 4
>     SearchRequest
>         baseDn : 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
>         filter : '(objectClass=*)'
>         scope : base object
>         typesOnly : false
>         Size Limit : no limit
>         Time Limit : no limit
>         Deref Aliases : deref Always
>         attributes : 'cn'
> org.apache.directory.api.ldap.model.message.SearchRequestImpl at 7887cbbc    ManageDsaITImpl Control
>         Type OID    : '2.16.840.1.113730.3.4.2'
>         Criticality : 'false'
> '
> : ERR_315 cannot create an entry under a referral when the Context.REFERRAL is set to 'ignore']; remaining name 'cn=refrole1,ou=ReferralRoles,dc=subtree,dc=keycloak,dc=org'
>         at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2971)
>         at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
>         at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1329)
>         at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235)
>         at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141)
>         at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129)
>         at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
>         at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
>         at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:313)
>         at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:217)
>         at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
>         at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
>         at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1716)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1741)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:470)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:465)
>         at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:750)
>         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.authorize(UsernamePasswordAuthenticationMechanism.java:92)
>         at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
>         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.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
>         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}
> Setting referrals=follows worked around the issue in this case.
> Steps to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1417272



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:49:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 10:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1455) ClassCastException when
 using yearMonthDuration in decision table
In-Reply-To: <JIRA.12679310.1488294598000@Atlassian.JIRA>
References: <JIRA.12679310.1488294598000@Atlassian.JIRA>
	<JIRA.12679310.1488294598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679310.1488294598000.1339.1488296940840@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370465#comment-13370465 ] 

Edson Tirelli commented on DROOLS-1455:
---------------------------------------

Good catch, java Period class (used for 'Years and Months Duration') does not implement Comparable<Period>, but java Duration class does implement Comparable<Duration>. 

I will add code to specifically handle Period comparisons.


> ClassCastException when using yearMonthDuration in decision table
> -----------------------------------------------------------------
>
>                 Key: DROOLS-1455
>                 URL: https://issues.jboss.org/browse/DROOLS-1455
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: M?lanie Gauthier
>            Assignee: Edson Tirelli
>         Attachments: yearMonthDuration.dmn
>
>
> Trying to run the attached example, a ClasCastException error is logged. dayTimeDuration works fine.
> A Period object is put in the context, created using 
> BuiltInType feelType = (BuiltInType) BuiltInType.determineTypeFromName(type);



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 10:51:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 10:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-459) Account for attribute groups
 in CLI behavior
In-Reply-To: <JIRA.12559216.1418253068000@Atlassian.JIRA>
References: <JIRA.12559216.1418253068000@Atlassian.JIRA>
	<JIRA.12559216.1418253068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12559216.1418253068000.1376.1488297060339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-459:
------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta7)


> Account for attribute groups in CLI behavior
> --------------------------------------------
>
>                 Key: WFCORE-459
>                 URL: https://issues.jboss.org/browse/WFCORE-459
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html
> This JIRA is for reflecting the attribute group notion in CLI behavior.
> I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:53:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 10:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.1411.1488297181456@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-266:
------------------------------------
    Fix Version/s: 4.0.0.Alpha1
                       (was: 3.0.0.Beta7)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:53:01 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 10:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the
 ParameterValidator constructor variants that accept allowNull and
 allowExpressions params
In-Reply-To: <JIRA.12557730.1416423853000@Atlassian.JIRA>
References: <JIRA.12557730.1416423853000@Atlassian.JIRA>
	<JIRA.12557730.1416423853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12557730.1416423853000.1422.1488297181726@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-266:
------------------------------------
    Fix Version/s:     (was: 4.0.0.Alpha1)


> Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-266
>                 URL: https://issues.jboss.org/browse/WFCORE-266
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>
> Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD.
> So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well.
> CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:55:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 10:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.1442.1488297300318@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370471#comment-13370471 ] 

Brian Stansberry commented on WFCORE-107:
-----------------------------------------

[~dlofthouse] I think this needs to be unscheduled or moved to 4.0.0.Beta1.

> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.0.Beta7
>
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:57:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 10:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.1459.1488297420578@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370474#comment-13370474 ] 

Brian Stansberry commented on WFCORE-1958:
------------------------------------------

Besides the one remaining test, I have no idea what this was about. :) I just reenabled a bunch of ignored tests because they pass and are needed to guard against regressions. But there may very well be some work that was meant to happen that still needs to happen.

> 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  Tue Feb 28 10:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 28 Feb 2017 10:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.1463.1488297420656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-107:
------------------------------------
    Fix Version/s:     (was: 3.0.0.Beta7)


> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 10:57:00 2017
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 28 Feb 2017 10:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to
 return authentication mechanism where verbose=true
In-Reply-To: <JIRA.12552224.1410808534000@Atlassian.JIRA>
References: <JIRA.12552224.1410808534000@Atlassian.JIRA>
	<JIRA.12552224.1410808534000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552224.1410808534000.1475.1488297420920@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370475#comment-13370475 ] 

Darran Lofthouse commented on WFCORE-107:
-----------------------------------------

Agreed, this is not easily accessible yet.

> Update whoami operation to return authentication mechanism where verbose=true
> -----------------------------------------------------------------------------
>
>                 Key: WFCORE-107
>                 URL: https://issues.jboss.org/browse/WFCORE-107
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>
> The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached.  
> This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 11:00:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 11:00: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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.1518.1488297600699@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar moved WFLY-7774 to JBEE-174:
----------------------------------------

              Project: JBoss JavaEE Spec APIs  (was: WildFly)
                  Key: JBEE-174  (was: WFLY-7774)
           Issue Type: Enhancement  (was: Bug)
             Workflow: classic default workflow  (was: GIT Pull Request workflow )
          Component/s: jboss-el-api
                           (was: EE)
       Target Release:   (was: 7.1.0.GA)
    Affects Version/s:     (was: 10.1.0.Final)


> 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
>            Reporter: Masafumi Miura
>            Assignee: Tomaz Cerar
>
> [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  Tue Feb 28 11:00:01 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 11:00:01 -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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.1534.1488297601491@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370478#comment-13370478 ] 

Tomaz Cerar commented on JBEE-174:
----------------------------------

[~rhatlapa] wdyt about introducing {{org.wildfly.el.bc2.2=true}} property for enabling this.

> 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
>            Reporter: Masafumi Miura
>            Assignee: Tomaz Cerar
>
> [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  Tue Feb 28 11:05:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 11:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does
 not get triggered on boot in subsystem-/core-model tests
In-Reply-To: <JIRA.12672105.1484843870000@Atlassian.JIRA>
References: <JIRA.12672105.1484843870000@Atlassian.JIRA>
	<JIRA.12672105.1484843870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672105.1484843870000.1617.1488297900611@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2217:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha1
                       (was: 4.0.0.Beta1)
                       (was: 3.0.0.Beta7)


[~kabirkhan] I'm removing this from the 3.0.0 schedule, as it seems complex and risky but not critical. If I'm wrong about that please reschedule.

> 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: Component Upgrade
>          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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                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<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            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  Tue Feb 28 11:28:02 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 28 Feb 2017 11:28:02 -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: <JIRA.12679337.1488299221000@Atlassian.JIRA>
References: <JIRA.12679337.1488299221000@Atlassian.JIRA>
	<JIRA.12679337.1488299221000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679337.1488299221000.1822.1488299282083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills moved JBEAP-9197 to WFCORE-2342:
------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-2342  (was: JBEAP-9197)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: CLI
                       Remoting
                       Security
                           (was: CLI)
                           (was: Remoting)
                           (was: Security)
    Affects Version/s:     (was: 7.1.0.DR12)
      Affects Testing:   (was: Regression)


> 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
>
> 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  Tue Feb 28 11:42:00 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 28 Feb 2017 11:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-981) Coverity static analysis:
 Performace optimalization in map iterating
In-Reply-To: <JIRA.12672890.1485278153000@Atlassian.JIRA>
References: <JIRA.12672890.1485278153000@Atlassian.JIRA>
	<JIRA.12672890.1485278153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672890.1485278153000.1889.1488300120130@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev moved WFLY-7956 to ELY-981:
-----------------------------------------

              Project: WildFly Elytron  (was: WildFly)
                  Key: ELY-981  (was: WFLY-7956)
          Component/s: HTTP
                           (was: Security)
    Affects Version/s:     (was: 11.0.0.Alpha1)


> Coverity static analysis: Performace optimalization in map iterating
> --------------------------------------------------------------------
>
>                 Key: ELY-981
>                 URL: https://issues.jboss.org/browse/ELY-981
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Minor
>
> Coverity static analysis found iterating over map can be enhanced
> https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=8486751&defectInstanceId=2122705&mergedDefectId=1389593
> Instead of Map.keySet() + Map.get() combo use just Map.entrySet().
>  
> {code:java|title=ElytronHttpExchange#getRequestParameters}
> for (String name : queryParameters.keySet()) {
>     List<String> values = new ArrayList<>(queryParameters.get(name));
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 11:46:01 2017
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Tue, 28 Feb 2017 11:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-981) Coverity static analysis:
 Performace optimalization in map iterating
In-Reply-To: <JIRA.12672890.1485278153000@Atlassian.JIRA>
References: <JIRA.12672890.1485278153000@Atlassian.JIRA>
	<JIRA.12672890.1485278153000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12672890.1485278153000.1941.1488300361221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev updated ELY-981:
------------------------------
    Affects Version/s: 1.1.0.Beta27


> Coverity static analysis: Performace optimalization in map iterating
> --------------------------------------------------------------------
>
>                 Key: ELY-981
>                 URL: https://issues.jboss.org/browse/ELY-981
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.1.0.Beta27
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Minor
>
> Coverity static analysis found iterating over map can be enhanced
> https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=8486751&defectInstanceId=2122705&mergedDefectId=1389593
> Instead of Map.keySet() + Map.get() combo use just Map.entrySet().
>  
> {code:java|title=ElytronHttpExchange#getRequestParameters}
> for (String name : queryParameters.keySet()) {
>     List<String> values = new ArrayList<>(queryParameters.get(name));
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 11:46:01 2017
From: issues at jboss.org (Ken Wills (JIRA))
Date: Tue, 28 Feb 2017 11:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2292) HTTPS / Native Management
 protocol mismatch when using SSL
In-Reply-To: <JIRA.12676456.1487007310000@Atlassian.JIRA>
References: <JIRA.12676456.1487007310000@Atlassian.JIRA>
	<JIRA.12676456.1487007310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12676456.1487007310000.1946.1488300361339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills resolved WFCORE-2292.
-------------------------------
    Resolution: Duplicate Issue


> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
>                 Key: WFCORE-2292
>                 URL: https://issues.jboss.org/browse/WFCORE-2292
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce8813189e66471c5b may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl at 2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial at aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel at 787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl at 1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password 
> Relevant bits of config in use:
> {quote}
>  <management>
>   <security-realms>
>   <security-realm name="sslSecurityRealm">
>     <server-identities>
>       <ssl>
>         <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
>       </ssl>
>     </server-identities>
>     <authentication>
>         <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
>     </authentication>
>   </security-realm>
>  </security-realms>
>  <management-interfaces>
>    <native-interface security-realm="sslSecurityRealm">
>     <socket-binding native="native"/>
>     </native-interface>
>     </management-interfaces>
>  </management>
>     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
>         <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
>         <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
>         <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
>     </socket-binding-group>
> {quote}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 12:01:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 28 Feb 2017 12:01: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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.2083.1488301260722@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370513#comment-13370513 ] 

Ivo Studensky commented on JBEE-174:
------------------------------------

[~rhatlapa] see JBEE-173 for property way

> 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
>            Reporter: Masafumi Miura
>            Assignee: Tomaz Cerar
>
> [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  Tue Feb 28 12:01:01 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 28 Feb 2017 12:01:01 -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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.2111.1488301261546@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370513#comment-13370513 ] 

Ivo Studensky edited comment on JBEE-174 at 2/28/17 12:00 PM:
--------------------------------------------------------------

[~rhatlapa] see JBEE-173 for the property way


was (Author: istudens):
[~rhatlapa] see JBEE-173 for property way

> 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
>            Reporter: Masafumi Miura
>            Assignee: Tomaz Cerar
>
> [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  Tue Feb 28 12:04:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 28 Feb 2017 12:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-173) Need system property to enable
 EL 2.2 backward compatible switch "javax.el.bc2.2"
In-Reply-To: <JIRA.12679223.1488292176000@Atlassian.JIRA>
References: <JIRA.12679223.1488292176000@Atlassian.JIRA>
	<JIRA.12679223.1488292176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679223.1488292176000.2126.1488301440086@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370515#comment-13370515 ] 

Ivo Studensky commented on JBEE-173:
------------------------------------

https://github.com/istudens/jboss-el-api_spec/commit/bf1bc6f5fc95e023f5d860ffed4c373c2977bb08

> Need system property to enable EL 2.2 backward compatible switch "javax.el.bc2.2"
> ---------------------------------------------------------------------------------
>
>                 Key: JBEE-173
>                 URL: https://issues.jboss.org/browse/JBEE-173
>             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: Ivo Studensky
>            Assignee: Ivo Studensky
>
> [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. User migration is blocked and needs system property to enable backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 12:33:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 12:33: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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.2200.1488303180413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated JBEE-174:
-----------------------------
    Affects Version/s: jboss-el-api_3.0_spec-1.0.7.Final


> 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
>
> [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  Tue Feb 28 12:33:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 12:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-173) Need system property to enable
 EL 2.2 backward compatible switch "javax.el.bc2.2"
In-Reply-To: <JIRA.12679223.1488292176000@Atlassian.JIRA>
References: <JIRA.12679223.1488292176000@Atlassian.JIRA>
	<JIRA.12679223.1488292176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679223.1488292176000.2205.1488303180551@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed JBEE-173.
----------------------------
    Resolution: Duplicate Issue


duplicate of JBEE-174

> Need system property to enable EL 2.2 backward compatible switch "javax.el.bc2.2"
> ---------------------------------------------------------------------------------
>
>                 Key: JBEE-173
>                 URL: https://issues.jboss.org/browse/JBEE-173
>             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: Ivo Studensky
>            Assignee: Ivo Studensky
>
> [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. User migration is blocked and needs system property to enable backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 12:34:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 12:34: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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.2218.1488303240592@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved JBEE-174.
------------------------------
    Fix Version/s: jboss-el-api_3.0_spec-1.0.8.Final
       Resolution: Done


> 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  Tue Feb 28 12:38:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8262) Upgrade to jboss-el-api
	1.0.8.Final
In-Reply-To: <JIRA.12679343.1488303432000@Atlassian.JIRA>
References: <JIRA.12679343.1488303432000@Atlassian.JIRA>
	<JIRA.12679343.1488303432066@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679343.1488303432000.2235.1488303480188@Atlassian.JIRA>

Tomaz Cerar created WFLY-8262:
---------------------------------

             Summary: Upgrade to jboss-el-api 1.0.8.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  Tue Feb 28 12:56:00 2017
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 28 Feb 2017 12:56: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: <JIRA.12666702.1481282547000@Atlassian.JIRA>
References: <JIRA.12666702.1481282547000@Atlassian.JIRA>
	<JIRA.12666702.1481282547000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12666702.1481282547000.2277.1488304560256@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370530#comment-13370530 ] 

Tomaz Cerar commented on JBEE-174:
----------------------------------

Introduced property new system property {{org.wildfly.el.bc2.2}}
It enables 2.2 backward compatibility only if org.wildfly.el.bc2.2=true 
Also keep in mind that this is system wide global configuration and as such cannot be configured per application.

> 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  Tue Feb 28 13:46:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 13:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2343)
 ExpressionResolverUnitTestCase uses a system prop named 'test'
In-Reply-To: <JIRA.12679349.1488307525000@Atlassian.JIRA>
References: <JIRA.12679349.1488307525000@Atlassian.JIRA>
	<JIRA.12679349.1488307525417@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679349.1488307525000.2513.1488307560459@Atlassian.JIRA>

Brian Stansberry created WFCORE-2343:
----------------------------------------

             Summary: ExpressionResolverUnitTestCase uses a system prop named 'test'
                 Key: WFCORE-2343
                 URL: https://issues.jboss.org/browse/WFCORE-2343
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


ExpressionResolverUnitTestCase does the and then checks the resolution of the expression returns "defaulted":

{code}
input.get("defaulted").set(new ValueExpression("${test:default}"));
{code}

That's fragile since the commonly used -Dtest=xxxx arg to maven will break it. 



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 15:01:00 2017
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 28 Feb 2017 15:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-173) Need system property to enable
 EL 2.2 backward compatible switch "javax.el.bc2.2"
In-Reply-To: <JIRA.12679223.1488292176000@Atlassian.JIRA>
References: <JIRA.12679223.1488292176000@Atlassian.JIRA>
	<JIRA.12679223.1488292176000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679223.1488292176000.2707.1488312060524@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBEE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370559#comment-13370559 ] 

Ivo Studensky commented on JBEE-173:
------------------------------------

Ok, thanks. I was in the middle of testing of my commit :)

> Need system property to enable EL 2.2 backward compatible switch "javax.el.bc2.2"
> ---------------------------------------------------------------------------------
>
>                 Key: JBEE-173
>                 URL: https://issues.jboss.org/browse/JBEE-173
>             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: Ivo Studensky
>            Assignee: Ivo Studensky
>
> [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. User migration is blocked and needs system property to enable backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 15:36:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 15:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1455) ClassCastException when
 using yearMonthDuration in decision table
In-Reply-To: <JIRA.12679310.1488294598000@Atlassian.JIRA>
References: <JIRA.12679310.1488294598000@Atlassian.JIRA>
	<JIRA.12679310.1488294598000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679310.1488294598000.2870.1488314160084@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370577#comment-13370577 ] 

Edson Tirelli commented on DROOLS-1455:
---------------------------------------

PR with the fix submitted.

> ClassCastException when using yearMonthDuration in decision table
> -----------------------------------------------------------------
>
>                 Key: DROOLS-1455
>                 URL: https://issues.jboss.org/browse/DROOLS-1455
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: M?lanie Gauthier
>            Assignee: Edson Tirelli
>         Attachments: yearMonthDuration.dmn
>
>
> Trying to run the attached example, a ClasCastException error is logged. dayTimeDuration works fine.
> A Period object is put in the context, created using 
> BuiltInType feelType = (BuiltInType) BuiltInType.determineTypeFromName(type);



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 16:09:03 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 28 Feb 2017 16:09:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8263) mod_cluster does not work
 with EJB/JNDI/Transactions over HTTP
In-Reply-To: <JIRA.12679363.1488316104000@Atlassian.JIRA>
References: <JIRA.12679363.1488316104000@Atlassian.JIRA>
	<JIRA.12679363.1488316104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679363.1488316104000.2980.1488316143139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-8263:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> mod_cluster does not work with EJB/JNDI/Transactions over HTTP
> --------------------------------------------------------------
>
>                 Key: WFLY-8263
>                 URL: https://issues.jboss.org/browse/WFLY-8263
>             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  Tue Feb 28 16:09:03 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 28 Feb 2017 16:09:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8263) mod_cluster does not work
 with EJB/JNDI/Transactions over HTTP
In-Reply-To: <JIRA.12679363.1488316104000@Atlassian.JIRA>
References: <JIRA.12679363.1488316104000@Atlassian.JIRA>
	<JIRA.12679363.1488316104399@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679363.1488316104000.2977.1488316143083@Atlassian.JIRA>

Stuart Douglas created WFLY-8263:
------------------------------------

             Summary: mod_cluster does not work with EJB/JNDI/Transactions over HTTP
                 Key: WFLY-8263
                 URL: https://issues.jboss.org/browse/WFLY-8263
             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  Tue Feb 28 16:09:03 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 28 Feb 2017 16:09:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8263) mod_cluster does not work
 with EJB/JNDI/Transactions over HTTP
In-Reply-To: <JIRA.12679363.1488316104000@Atlassian.JIRA>
References: <JIRA.12679363.1488316104000@Atlassian.JIRA>
	<JIRA.12679363.1488316104000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679363.1488316104000.2987.1488316143333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-8263:
---------------------------------
    Component/s: mod_cluster
                 Web (Undertow)


> mod_cluster does not work with EJB/JNDI/Transactions over HTTP
> --------------------------------------------------------------
>
>                 Key: WFLY-8263
>                 URL: https://issues.jboss.org/browse/WFLY-8263
>             Project: WildFly
>          Issue Type: Bug
>          Components: mod_cluster, Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 16:09:03 2017
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 28 Feb 2017 16:09:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8264) mod_cluster does not work
 with EJB/JNDI/Transactions over HTTP
In-Reply-To: <JIRA.12679364.1488316125000@Atlassian.JIRA>
References: <JIRA.12679364.1488316125000@Atlassian.JIRA>
	<JIRA.12679364.1488316125419@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679364.1488316125000.2989.1488316143377@Atlassian.JIRA>

Stuart Douglas created WFLY-8264:
------------------------------------

             Summary: mod_cluster does not work with EJB/JNDI/Transactions over HTTP
                 Key: WFLY-8264
                 URL: https://issues.jboss.org/browse/WFLY-8264
             Project: WildFly
          Issue Type: Bug
          Components: mod_cluster, Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 16:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 16:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2344) Changing management
 interface with allow-resource-service-restart ends in reload-required state
In-Reply-To: <JIRA.12678949.1488178347000@Atlassian.JIRA>
References: <JIRA.12678949.1488178347000@Atlassian.JIRA>
	<JIRA.12678949.1488178347000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678949.1488178347000.3097.1488317160453@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-8244 to WFCORE-2344:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2344  (was: WFLY-8244)
    Component/s: Domain Management
                 Security
                     (was: Security)


> Changing management interface with allow-resource-service-restart ends in reload-required state
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2344
>                 URL: https://issues.jboss.org/browse/WFCORE-2344
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>
> If I try to change elytron authentication for management interface with header {{allow-resource-service-restart=true}} server ends in {{reload-required}} state. 
> {code}
> [standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-http-authentication){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. 
> If it can't be implemented for some reason, rather throw UnsupportedOperationException - it seems to me to be more fair.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 16:26:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 16:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2344) Changing management
 interface with allow-resource-service-restart ends in reload-required state
In-Reply-To: <JIRA.12678949.1488178347000@Atlassian.JIRA>
References: <JIRA.12678949.1488178347000@Atlassian.JIRA>
	<JIRA.12678949.1488178347000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678949.1488178347000.3104.1488317160604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2344:
----------------------------------------

    Assignee: Brian Stansberry  (was: Darran Lofthouse)


> Changing management interface with allow-resource-service-restart ends in reload-required state
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2344
>                 URL: https://issues.jboss.org/browse/WFCORE-2344
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Martin Choma
>            Assignee: Brian Stansberry
>
> If I try to change elytron authentication for management interface with header {{allow-resource-service-restart=true}} server ends in {{reload-required}} state. 
> {code}
> [standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-authentication-factory, value=application-http-authentication){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. 
> If it can't be implemented for some reason, rather throw UnsupportedOperationException - it seems to me to be more fair.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8254) Changing
 sasl-authentication-factory in management interface ends in reload-required
 state
In-Reply-To: <JIRA.12679125.1488265529000@Atlassian.JIRA>
References: <JIRA.12679125.1488265529000@Atlassian.JIRA>
	<JIRA.12679125.1488265529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679125.1488265529000.3113.1488317640401@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370589#comment-13370589 ] 

Brian Stansberry commented on WFLY-8254:
----------------------------------------

Please file bugs against kernel resources in WFCORE.

> Changing sasl-authentication-factory in management interface ends in reload-required state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-8254
>                 URL: https://issues.jboss.org/browse/WFLY-8254
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>
> Attribute sasl-authentication-factory is described as follows
> {code}
>     "sasl-authentication-factory" => {
>         "type" => STRING,
>         "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
>         "expressions-allowed" => false,
>         "required" => false,
>         "nillable" => true,
>         "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
>         "min-length" => 1L,
>         "max-length" => 2147483647L
>     }
> {code}
> Documenation [1] says:
> 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.
> But when I try to change it I get:
> {code}
> [standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> Probably some proper value for "restart-required" should be used. "restart-required" => "all-services" ?
> [1] https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2345) Changing
 sasl-authentication-factory in management interface ends in reload-required
 state
In-Reply-To: <JIRA.12679125.1488265529000@Atlassian.JIRA>
References: <JIRA.12679125.1488265529000@Atlassian.JIRA>
	<JIRA.12679125.1488265529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679125.1488265529000.3120.1488317640595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-8254 to WFCORE-2345:
------------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2345  (was: WFLY-8254)
    Component/s: Domain Management
                 Security
                     (was: Security)


> Changing sasl-authentication-factory in management interface ends in reload-required state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2345
>                 URL: https://issues.jboss.org/browse/WFCORE-2345
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>
> Attribute sasl-authentication-factory is described as follows
> {code}
>     "sasl-authentication-factory" => {
>         "type" => STRING,
>         "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
>         "expressions-allowed" => false,
>         "required" => false,
>         "nillable" => true,
>         "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
>         "min-length" => 1L,
>         "max-length" => 2147483647L
>     }
> {code}
> Documenation [1] says:
> 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.
> But when I try to change it I get:
> {code}
> [standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> Probably some proper value for "restart-required" should be used. "restart-required" => "all-services" ?
> [1] https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 16:34:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 16:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2345) Changing
 sasl-authentication-factory in management interface ends in reload-required
 state
In-Reply-To: <JIRA.12679125.1488265529000@Atlassian.JIRA>
References: <JIRA.12679125.1488265529000@Atlassian.JIRA>
	<JIRA.12679125.1488265529000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679125.1488265529000.3127.1488317640912@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2345:
----------------------------------------

    Assignee: Brian Stansberry  (was: Darran Lofthouse)


> Changing sasl-authentication-factory in management interface ends in reload-required state
> ------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2345
>                 URL: https://issues.jboss.org/browse/WFCORE-2345
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, Security
>            Reporter: Martin Choma
>            Assignee: Brian Stansberry
>
> Attribute sasl-authentication-factory is described as follows
> {code}
>     "sasl-authentication-factory" => {
>         "type" => STRING,
>         "description" => "The server side SASL authentication policy to use to secure the interface where the connection is after a HTTP upgrade.",
>         "expressions-allowed" => false,
>         "required" => false,
>         "nillable" => true,
>         "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
>         "min-length" => 1L,
>         "max-length" => 2147483647L
>     }
> {code}
> Documenation [1] says:
> 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.
> But when I try to change it I get:
> {code}
> [standalone at localhost:9990 /] /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=application-sasl-authentication)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> {code}
> Probably some proper value for "restart-required" should be used. "restart-required" => "all-services" ?
> [1] https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 17:00:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 17:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1456) Improve error messages and
 error handling on DMN compilation and execution
In-Reply-To: <JIRA.12679369.1488319171000@Atlassian.JIRA>
References: <JIRA.12679369.1488319171000@Atlassian.JIRA>
	<JIRA.12679369.1488319171354@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679369.1488319171000.3194.1488319200092@Atlassian.JIRA>

Edson Tirelli created DROOLS-1456:
-------------------------------------

             Summary: 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. etc



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 17:10:00 2017
From: issues at jboss.org (Kalyan gogineni (JIRA))
Date: Tue, 28 Feb 2017 17:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1457) Guided rules editor
 function field does not perform semantic validation
In-Reply-To: <JIRA.12679372.1488319741000@Atlassian.JIRA>
References: <JIRA.12679372.1488319741000@Atlassian.JIRA>
	<JIRA.12679372.1488319741716@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679372.1488319741000.3229.1488319800163@Atlassian.JIRA>

Kalyan gogineni created DROOLS-1457:
---------------------------------------

             Summary: Guided rules editor function field does not perform semantic validation
                 Key: DROOLS-1457
                 URL: https://issues.jboss.org/browse/DROOLS-1457
             Project: Drools
          Issue Type: Feature Request
          Components: build
            Reporter: Kalyan gogineni
            Assignee: Petr ?irok?


guided rules editor function field does not perform semantic validation.
 For example: when you define rules like below

When number 1 is not null
And number 2 is not null
Then number 3 = number5/number1

Note: Where number5 is not defined. Then when you compile or build and deploy then drools does not throw error.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 17:50:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 28 Feb 2017 17:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1457) Guided rules editor
 function field does not perform semantic validation
In-Reply-To: <JIRA.12679372.1488319742000@Atlassian.JIRA>
References: <JIRA.12679372.1488319742000@Atlassian.JIRA>
	<JIRA.12679372.1488319742000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679372.1488319742000.3328.1488322200229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? updated DROOLS-1457:
--------------------------------
    Component/s:     (was: build)


> Guided rules editor function field does not perform semantic validation
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1457
>                 URL: https://issues.jboss.org/browse/DROOLS-1457
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kalyan gogineni
>            Assignee: Petr ?irok?
>
> guided rules editor function field does not perform semantic validation.
>  For example: when you define rules like below
> When number 1 is not null
> And number 2 is not null
> Then number 3 = number5/number1
> Note: Where number5 is not defined. Then when you compile or build and deploy then drools does not throw error.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 17:51:00 2017
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 28 Feb 2017 17:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1457) Guided rules editor
 function field does not perform semantic validation
In-Reply-To: <JIRA.12679372.1488319742000@Atlassian.JIRA>
References: <JIRA.12679372.1488319742000@Atlassian.JIRA>
	<JIRA.12679372.1488319742000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679372.1488319742000.3332.1488322260109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1457:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Guided rules editor function field does not perform semantic validation
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-1457
>                 URL: https://issues.jboss.org/browse/DROOLS-1457
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Kalyan gogineni
>
> guided rules editor function field does not perform semantic validation.
>  For example: when you define rules like below
> When number 1 is not null
> And number 2 is not null
> Then number 3 = number5/number1
> Note: Where number5 is not defined. Then when you compile or build and deploy then drools does not throw error.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 18:08:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 18:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2346) Revisit enforcement of
 required file system permissions.
In-Reply-To: <JIRA.12486809.1362763320000@Atlassian.JIRA>
References: <JIRA.12486809.1362763320000@Atlassian.JIRA>
	<JIRA.12486809.1362763320000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486809.1362763320000.3347.1488323280306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry moved WFLY-431 to WFCORE-2346:
-----------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-2346  (was: WFLY-431)
    Component/s: Domain Management
                     (was: Domain Management)


> Revisit enforcement of required file system permissions.
> --------------------------------------------------------
>
>                 Key: WFCORE-2346
>                 URL: https://issues.jboss.org/browse/WFCORE-2346
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: management_security,
>
> Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 18:10:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 18:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3759) Make IP address of remote EJB
 client accessible to the developer from within app authentication code
In-Reply-To: <JIRA.12549965.1408652292000@Atlassian.JIRA>
References: <JIRA.12549965.1408652292000@Atlassian.JIRA>
	<JIRA.12549965.1408652292000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549965.1408652292000.3355.1488323400352@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-3759:
-----------------------------------
    Component/s: EJB
                     (was: Domain Management)


> Make IP address of remote EJB client accessible to the developer from within app authentication code
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-3759
>                 URL: https://issues.jboss.org/browse/WFLY-3759
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB, Security
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>
> Make the IP address of remote EJB clients accessible from within a login module login module when the security-realm is configured to defer to JAAS.
> This is possible when the authentication is handled by the security-realm, but it is not possible when the security-realm defers to a security-domain (JAAS).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 18:23:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 18:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8023) Autocomplete doesn't work
 properly in credential-reference.alias attribute.
In-Reply-To: <JIRA.12674774.1486124190000@Atlassian.JIRA>
References: <JIRA.12674774.1486124190000@Atlassian.JIRA>
	<JIRA.12674774.1486124190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674774.1486124190000.3369.1488324180687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-8023:
-----------------------------------
    Issue Type: Enhancement  (was: Bug)


This is not information available to the CLI via any standard tab completion mechanism and thus is an RFE.

> Autocomplete doesn't work properly in credential-reference.alias attribute.
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-8023
>                 URL: https://issues.jboss.org/browse/WFLY-8023
>             Project: WildFly
>          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=<TAB>
> {code}



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 18:58:00 2017
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 28 Feb 2017 18:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron
	registration
In-Reply-To: <JIRA.12660224.1478619843000@Atlassian.JIRA>
References: <JIRA.12660224.1478619843000@Atlassian.JIRA>
	<JIRA.12660224.1478619843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660224.1478619843000.3398.1488326280868@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370608#comment-13370608 ] 

Brian Stansberry commented on WFCORE-1958:
------------------------------------------

https://github.com/wildfly/wildfly-core/pull/2218 reenables the last @Ignored test, since it passes for me locally.

> 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  Tue Feb 28 22:20:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 22:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1456) Improve error messages and
 error handling on DMN compilation and execution
In-Reply-To: <JIRA.12679369.1488319171000@Atlassian.JIRA>
References: <JIRA.12679369.1488319171000@Atlassian.JIRA>
	<JIRA.12679369.1488319171000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679369.1488319171000.4397.1488338400062@Atlassian.JIRA>


     [ 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. Fix compilation error for models with BKM nodes that depend on other BKM nodes.

  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. etc



> 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. Fix compilation error for models with BKM nodes that depend on other BKM nodes.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 22:23:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 22:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1458) Compilation error when
 compiling DMN model with a BKM node that depends on another BKM node
In-Reply-To: <JIRA.12679378.1488338567000@Atlassian.JIRA>
References: <JIRA.12679378.1488338567000@Atlassian.JIRA>
	<JIRA.12679378.1488338567900@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679378.1488338567000.4399.1488338580074@Atlassian.JIRA>

Edson Tirelli created DROOLS-1458:
-------------------------------------

             Summary: Compilation error when compiling DMN model with a BKM node that depends on another BKM node
                 Key: DROOLS-1458
                 URL: https://issues.jboss.org/browse/DROOLS-1458
             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


When a DMN model contains a BKM node that depends on another BKM node, the compiler raises an error like:

`Error compiling FEEL expression 'monthlyPayment(loanAmt,rate,360)' for name 'paymentAmt' on node 'FinancialMetrics': Unknown variable 'monthlyPayment'`



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Feb 28 22:24:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 22:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1456) Improve error messages and
 error handling on DMN compilation and execution
In-Reply-To: <JIRA.12679369.1488319171000@Atlassian.JIRA>
References: <JIRA.12679369.1488319171000@Atlassian.JIRA>
	<JIRA.12679369.1488319171000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679369.1488319171000.4401.1488338640055@Atlassian.JIRA>


     [ 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.

  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.

3. Fix compilation error for models with BKM nodes that depend on other BKM nodes.



> 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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)


From issues at jboss.org  Tue Feb 28 22:29:00 2017
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 28 Feb 2017 22:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1458) Compilation error when
 compiling DMN model with a BKM node that depends on another BKM node
In-Reply-To: <JIRA.12679378.1488338568000@Atlassian.JIRA>
References: <JIRA.12679378.1488338568000@Atlassian.JIRA>
	<JIRA.12679378.1488338568000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679378.1488338568000.4404.1488338940041@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13370621#comment-13370621 ] 

Edson Tirelli commented on DROOLS-1458:
---------------------------------------

Pull request submitted.

> Compilation error when compiling DMN model with a BKM node that depends on another BKM node
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1458
>                 URL: https://issues.jboss.org/browse/DROOLS-1458
>             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
>
>
> When a DMN model contains a BKM node that depends on another BKM node, the compiler raises an error like:
> `Error compiling FEEL expression 'monthlyPayment(loanAmt,rate,360)' for name 'paymentAmt' on node 'FinancialMetrics': Unknown variable 'monthlyPayment'`



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

