[JBoss JIRA] (WFCORE-442) AbstractMultiTargetHandler-based handlers do not propagate failures to the top level failure-description
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-442?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-442:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> AbstractMultiTargetHandler-based handlers do not propagate failures to the top level failure-description
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-442
> URL: https://issues.jboss.org/browse/WFCORE-442
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha13
> Reporter: Brian Stansberry
> Assignee: Heiko Braun
> Fix For: 1.0.0.CR1
>
>
> An example is worth a thousand words:
> {code}
> [standalone@localhost:9990 /] /path=*:query(where={read-only=1})
> {
> "outcome" => "failed",
> "result" => [
> {
> "address" => [("path" => "jboss.server.temp.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.temp.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/tmp",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "user.home")],
> "outcome" => "failed",
> "result" => {
> "name" => "user.home",
> "path" => "/Users/hbraun",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.base.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.base.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "java.home")],
> "outcome" => "failed",
> "result" => {
> "name" => "java.home",
> "path" => "/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "user.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "user.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.data.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.data.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/data",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.home.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.home.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.log.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.log.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/log",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.server.config.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.server.config.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/configuration",
> "read-only" => true,
> "relative-to" => undefined
> },
> "rolled-back" => true
> },
> {
> "address" => [("path" => "jboss.controller.temp.dir")],
> "outcome" => "failed",
> "result" => {
> "name" => "jboss.controller.temp.dir",
> "path" => "/Users/hbraun/dev/prj/wildfly-core/core-build/target/wildfly-core-1.0.0.Alpha14-SNAPSHOT/standalone/tmp",
> "read-only" => true,
> "relative-to" => undefined
> },
> "failure-description" => "Illegal argument for attribute 'read-only'. Expected type BOOLEAN",
> "rolled-back" => true
> }
> ],
> "rolled-back" => true
> }
> {code}
> One item in the set has a failure description but the overall response does not.
> ReadResourceDescriptionHandler handles similar things but has logic for creating an overall failure-description.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-602) Ability to view an objects index of it's position in a list.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-602?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-602:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Ability to view an objects index of it's position in a list.
> ------------------------------------------------------------
>
> Key: WFCORE-602
> URL: https://issues.jboss.org/browse/WFCORE-602
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Labels: affects_elytron
> Fix For: 1.0.0.CR1
>
>
> General improvements are being made to the management model for more fine grained manipulation of complex attributes, amongst these changes will be the ability to insert items at a specific position in a list.
> This feature request is to ask for the ability to see an items index to identify it's position.
> i.e. an end user can call :read-recource and see an items position without needing to count how many items there are in order to identify the position of the next insert.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-597) Where an ObjectTypeAttributeDefinition is in use respect the ResourceOnly setting on contained types for add operations.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-597?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-597:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> 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: 1.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.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-580?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-580:
----------------------------------
Fix Version/s: 1.0.0.CR1
(was: 1.0.0.Beta1)
> Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-580
> URL: https://issues.jboss.org/browse/WFCORE-580
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 1.0.0.CR1
>
>
> Take the following hierarchy: -
> keystore=xxx
> alias=yyy
> certificate-chain=default
> certificate-chain=x509
> keystore is a regular resource with storage=configuration.
> alias is a regular resource with storage=runtime
> certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime.
> So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain.
> The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist.
> For the singleton resources however the following method is called: -
> {code}
> org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String)
> {code}
> Within this method the following check takes place: -
> {code}
> if (resource != null && resource.hasChildren(childType)) {
> Set<String> childNames = resource.getChildrenNames(childType);
> if (element.isWildcard()) {
> set.addAll(childNames);
> } else if (childNames.contains(element.getValue())) {
> set.add(element.getValue());
> }
> {code}
> Up to this point all is fine, the children the resource claims are available are the only ones added.
> But further down this happens: -
> {code}
> if (!element.isWildcard()) {
> ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element));
> if (childReg != null && childReg.isRuntimeOnly()) {
> set.add(element.getValue());
> }
> }
> {code}
> So even though the resource was previously checked and missing children excluded they are now added back.
> The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation.
> From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated REMJMX-94:
-----------------------------------
Fix Version/s: 2.0.1.CR2
> Memory leak in remoting-jmx
> ---------------------------
>
> Key: REMJMX-94
> URL: https://issues.jboss.org/browse/REMJMX-94
> Project: Remoting JMX
> Issue Type: Bug
> Affects Versions: 1.1.3.Final
> Reporter: Libor Zoubek
> Assignee: Darran Lofthouse
> Labels: memory_leak
> Fix For: 2.0.1.CR2
>
>
> In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed.
> I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps:
> 1. start new thread
> 2. assign URL classloader to this thread (point it to jboss-client.jar)
> 3. connect & disconnect to jmx-remoting endpoint
> In this test no classes don't get GCed which after serveral iterations ends up in OOM.
> My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
> I am not sure if memleak is in remoting-jmx or some other underlying stuff.
> I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months