August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5241) Update messaging subsystem descriptions to properly report path cardinality

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-5241: -------------------------------------- Summary: Update messaging subsystem descriptions to properly report path cardinality Key: WFLY-5241 URL: https://issues.jboss.org/browse/WFLY-5241 Project: WildFly Issue Type: Task Components: JMS Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 10.0.0.CR1 https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... has been updated to more intelligently report cardinality information about resource registrations, with each reg reporting its own cardinality instead of having the parent report data about the "key" portion of potentially unrelated children. The two messaging subsystems are actually trying to use the old way for "path" children, so this JIRA is to move to the new way. Instead of the parent resource reporting there must be 4 and no more than 4 children with key "path", now each of the 4 valid path children types will report that the min-occurs of that type is 1. (The max-occurs is also 1, but that will not be reported as that, per the spec, is the default for a 'singleton' type, and each of the 4 path types is a singleton.) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-621: ------------------------------------ Description: This is a follow-on to WFCORE-282. The WFCORE-282 solution will not work for requests with address patterns {code}/host=*/server=*{code} or {code}/host=somename/server=*{code} if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.) In particular, it won't work with slaves running EAP 6.x. The problem is with either of those address patterns the DC will send a request addressed to {code}/host=somename/server=*{code} to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them. Potentially this could be fixed by having the DC detect these patterns and not call {code}/host=somename/server=*{code}, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc. was: This is a follow-on to WFCORE-282. The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.) In particular, it won't work with slaves running EAP 6.x. The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them. Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc. > Support legacy slaves when invoking wildcard reads in a domain > -------------------------------------------------------------- > > Key: WFCORE-621 > URL: https://issues.jboss.org/browse/WFCORE-621 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Critical > Fix For: 2.0.0.CR1 > > > This is a follow-on to WFCORE-282. > The WFCORE-282 solution will not work for requests with address patterns {code}/host=*/server=*{code} or {code}/host=somename/server=*{code} if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.) > In particular, it won't work with slaves running EAP 6.x. > The problem is with either of those address patterns the DC will send a request addressed to {code}/host=somename/server=*{code} to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them. > Potentially this could be fixed by having the DC detect these patterns and not call {code}/host=somename/server=*{code}, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-395) Improve reporting during deployment hang

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-395?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-395: ------------------------------------ Fix Version/s: (was: 2.0.0.CR1) > Improve reporting during deployment hang > ---------------------------------------- > > Key: WFCORE-395 > URL: https://issues.jboss.org/browse/WFCORE-395 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: http://java.net/jira/browse/EJB_SPEC-60 > java version "1.7.0_09" > OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Ubuntu 12.10 > Reporter: Carlo de Wolf > Assignee: Brian Stansberry > Attachments: deployment-hang-20130205.txt, server.log > > > Management Thread waits indefinitely for, what seems to be, a finished operation. > {noformat} > "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158) > - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464) > at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-395) Improve reporting during deployment hang

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-395?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-395: --------------------------------------- Assignee: (was: Brian Stansberry) > Improve reporting during deployment hang > ---------------------------------------- > > Key: WFCORE-395 > URL: https://issues.jboss.org/browse/WFCORE-395 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Environment: http://java.net/jira/browse/EJB_SPEC-60 > java version "1.7.0_09" > OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1) > OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) > Ubuntu 12.10 > Reporter: Carlo de Wolf > Attachments: deployment-hang-20130205.txt, server.log > > > Management Thread waits indefinitely for, what seems to be, a finished operation. > {noformat} > "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at java.lang.Object.wait(Object.java:503) > at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158) > - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor) > at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464) > at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-54: ----------------------------------- Fix Version/s: 3.0.0.Beta1 (was: 2.0.0.CR1) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 3.0.0.Beta1 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4850) ManagementClient.isServerInRunningState fails when server is stopped

by Vitalii Chepeliuk (JIRA)

[ https://issues.jboss.org/browse/WFLY-4850?page=com.atlassian.jira.plugin.... ] Vitalii Chepeliuk commented on WFLY-4850: ----------------------------------------- Hey guys! We do have wildfly-arquillian JIRA here https://issues.jboss.org/browse/WFCORE-837 > ManagementClient.isServerInRunningState fails when server is stopped > -------------------------------------------------------------------- > > Key: WFLY-4850 > URL: https://issues.jboss.org/browse/WFLY-4850 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ondřej Chaloupka > Assignee: James Perkins > > Scenario: server is stopped (killed), working with arquillian to check if server is started or not > Current implementation of the {{ManagementClient.isServerInRunningState}} catches only {{IOException}} (see [1]) and in such case false is returned. Otherwise exception is propagated upwards. > That's a problem in case that assertions are enabled - which is true statement for wildfly testsuite (see pom.xml, surefire configuration and {{<enableAssertions>true</enableAssertions>}}). As state of the server is checked with assertions as well [2] then test fails on such assertion instead of getting false as server is stopped. > In comparision with arquillian client for jboss-eap there is caught {{Throwable}} and returned false [3] which seems to me more correct. > Could you, please, forwardport arquillian client behaviour from JBoss EAP to WildFly? > [1] https://github.com/wildfly/wildfly-arquillian/blob/master/common/src/main... > [2] https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > [3] https://github.com/jbossas/jboss-eap/blob/6.x/arquillian/common/src/main/... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-811) Add module for org.wildfly.security.elytron-web:undertow-server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-811?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-811: ------------------------------------ Fix Version/s: 3.0.0.Alpha1 (was: 2.0.0.Alpha9) > Add module for org.wildfly.security.elytron-web:undertow-server > --------------------------------------------------------------- > > Key: WFCORE-811 > URL: https://issues.jboss.org/browse/WFCORE-811 > Project: WildFly Core > Issue Type: Sub-task > Components: Modules > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha1 > > > This is the module that provides the integration between Elytron and Undertow without each needing to be aware of the other. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-811) Add module for org.wildfly.security.elytron-web:undertow-server

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-811?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-811: --------------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) > Add module for org.wildfly.security.elytron-web:undertow-server > --------------------------------------------------------------- > > Key: WFCORE-811 > URL: https://issues.jboss.org/browse/WFCORE-811 > Project: WildFly Core > Issue Type: Sub-task > Components: Modules > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha1 > > > This is the module that provides the integration between Elytron and Undertow without each needing to be aware of the other. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-597) Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-597?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-597: ------------------------------------ Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Alpha9) > Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations. > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-597 > URL: https://issues.jboss.org/browse/WFCORE-597 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 2.0.0.CR1 > > > If an ObjectTypeAttributeDefinition contains an attribute definition that has ResourceOnly set then it should be filtered from the automatically generated description for the add operation. > This may be more related to lists, I currently have: - > ObjectListAttributeDefinition, which contains ObjectTypeAttributeDefinition, which contains SimpleAttributeDefinition > It is this final SimpleAttributeDefinition that has ResourceOnly set but it is still showing up in the operation description for add. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-714) Integrate Elytron with the Remoting subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-714?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-714: ------------------------------------ Fix Version/s: 3.0.0.Beta1 (was: 2.0.0.Alpha9) > Integrate Elytron with the Remoting subsystem > --------------------------------------------- > > Key: WFCORE-714 > URL: https://issues.jboss.org/browse/WFCORE-714 > Project: WildFly Core > Issue Type: Sub-task > Components: Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015