[JBoss JIRA] (WFCORE-403) Evaluate making operation "composite" EntryType.PUBLIC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-403?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-403:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 1.0.0.CR1)
> Evaluate making operation "composite" EntryType.PUBLIC
> ------------------------------------------------------
>
> Key: WFCORE-403
> URL: https://issues.jboss.org/browse/WFCORE-403
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> When the composite operation handler is registered, it's marked as EntryType.PRIVATE. This operation really isn't private; any reasonable management client will need to invoke it.
> Changing it may have some implications though; we need to evaluate those. The biggest is the operation metadata cannot be complete, because the step parameter elements cannot be fully described.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[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: 2.0.0.CR1
(was: 1.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
> Fix For: 2.0.0.CR1
>
> 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.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-396:
-----------------------------------------
If this slips to 2.0.0.Beta1 that's fine. Please reschedule it if you think that's likely.
> 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: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Fix For: 1.0.0.CR1
>
>
> 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
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-43:
----------------------------------------
If this slips to 2.0.0.Beta1 that's fine. Please reschedule it if you think that's likely.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: luck3y
> Fix For: 1.0.0.CR1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQURIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-379) Give option to make the content repository browsable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-379?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-379:
---------------------------------------
Fix Version/s: (was: 1.0.0.CR1)
Assignee: luck3y
Ken, I'm assigning this to you as it's in the area of content repository management where you have a couple other tasks.
> Give option to make the content repository browsable
> ----------------------------------------------------
>
> Key: WFCORE-379
> URL: https://issues.jboss.org/browse/WFCORE-379
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Schofield
> Assignee: luck3y
>
> JBoss admins regularly need to view the application content that is deployed to a server. On previous versions of JBoss this was easy to do with the deploy directory. When using the new API to install applications the contents of applications are not easily browsable or searchable.
> Would like to have a setting that enables all content to be stored in exploded format in the content repository.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFCORE-626:
------------------------------------
tests for global collection operations are in org.jboss.as.controller.operation.global.CollectionOperationsTestCase.
I agree that fix is correct, i just want to also add tests for this, for future proofing it.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-626) Global list-get operation can inadvertently create list elements
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-626?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFCORE-626:
-------------------------------------
Thanks. I didn't find any tests for these global operations - though I validated this particular fix against my tests for WFLY-4488.
> Global list-get operation can inadvertently create list elements
> ----------------------------------------------------------------
>
> Key: WFCORE-626
> URL: https://issues.jboss.org/browse/WFCORE-626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Tomaz Cerar
> Fix For: 1.0.0.CR1
>
>
> Consider the following sequence of operations:
> # :list-clear(name=attribute)
> # :list-get(name=attribute, index=0)
> # :list-add(name=attribute, value=test)
> # :list-get(name=attribute, index=0)
> #2 will return <undefined> as expected. The expected result of #4 is "test". However, it returns <undefined>. This is because #2 will create the missing element at index 0 causing #3 to operate on index 1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-387) Describe inheritance relationships in the resource description metadata
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-387?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-387:
------------------------------------
Fix Version/s: (was: 1.0.0.CR1)
> Describe inheritance relationships in the resource description metadata
> -----------------------------------------------------------------------
>
> Key: WFCORE-387
> URL: https://issues.jboss.org/browse/WFCORE-387
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
>
> Some elements in the management model have an inheritance relationship with other elements located elsewhere. For example, system properties can be defined as a child of the root domain resource, as a child of a server-group resource, as a child of the root host resource, and as a child of the server-config resource.
> The resource description metadata for a resource needs to describe these relationships. It needs to cover the inheritance hierarchy, as well as how any conflicts are resolved (i.e. does the child win, as is the case with system properties and interfaces, or is some sort of merging strategy employed, as is the case with profiles and socket-binding-groups, where the sets of child resources (subsystems and socket-bindings) are merged, provided that the two sets are disjoint.
> A factor to include in this metadata is whether the relationship is fixed (i.e. host system-property inherits from server-group) or whether there is some attribute that defines the inheritance (e.g. a profile's that "includes" another profile has an attribute that defines the name of the included profile.)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months