[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFCORE-351:
-----------------------------------
[~brian.stansberry] You're right :shutdown(restart=true) does not allow you to specify a different config. Since this is controlled by the script, and the process is completely dead in the meantime, I don't see any obvious/easy way to make this happen.
reload-required is a a lot more popular (currently at least!) than restart-required. But of course that depends on the project building on top of core.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1628) Create module using 'module add' CLI command with absolute-path in resource-root element
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1628?page=com.atlassian.jira.plugi... ]
Martin Simka updated WFCORE-1628:
---------------------------------
Description:
MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
{quote}
resource-root's path previously only allowed resources within the module's directory, e.g.:
<resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
<resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
{quote}
{{module add}} command could have optional argument {{--copy-resources=(true|false)}}, which would specify how new module will look like.
* {{true}} copy files to the created module's directory = no change from how it works now.
* {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
was:
MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
{quote}
resource-root's path previously only allowed resources within the module's directory, e.g.:
<resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
<resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
{quote}
> Create module using 'module add' CLI command with absolute-path in resource-root element
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1628
> URL: https://issues.jboss.org/browse/WFCORE-1628
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Martin Simka
> Assignee: Alexey Loubyansky
>
> MODULES-218, included in WildFly 10/WildFly Core 2.0.10, allows absolute paths to be used for resource-roots in module.xml. But there is no way to create module with absolute paths in resource-roots using CLI command {{module add}}.
> {quote}
> resource-root's path previously only allowed resources within the module's directory, e.g.:
> <resource-root path="wildfly-controller-2.2.0.CR2.jar"/>
> With MODULES-218 it allows resources to exist anywhere on the filesystem, in the form of an absolute path, e.g.:
> <resource-root path="/Users/whoever/mymodules/wildfly-controller-2.2.0.CR2.jar"/>
> {quote}
> {{module add}} command could have optional argument {{--copy-resources=(true|false)}}, which would specify how new module will look like.
> * {{true}} copy files to the created module's directory = no change from how it works now.
> * {{false}} don't copy files and use absolute paths in {{resource-root}} instead.
> Another option could be to add optional argument without value, which would only specify to not copy files to the created module's directory and use absolute paths in {{resource-root}} instead. Name of this argument could be something like {{--use-absolute-paths-for-resources}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1630?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1630:
------------------------------------------
I updated the description to include some more text just in case it helps a searcher find this. The big issue here was that the logic to synchronize a slave HC after reconnecting to the master was generating undefine-attribute ops that were then not handled. Turning on assertions led to the failure being reported but the real failure was the operations were not handled.
> Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1630
> URL: https://issues.jboss.org/browse/WFCORE-1630
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.2.0.CR5, 3.0.0.Alpha3
>
>
> When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
> {noformat}
> [Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> {noformat}
> This was observed in a failure of OrderedChildResourcesTestCase.
> Failed tests:
> OrderedChildResourcesTestCase.testOrderedChildResources:124 expected:<{
> "protocol" => {
> "MPING" => undefined,
> "MERGE3" => undefined,
> "FD_SOCK" => undefined,
> "FD" => undefined,
> "VERIFY_SUSPECT" => undefined,
> "pbcast.NAKACK2" => undefined,
> "UNICAST3" => undefined,
> "pbcast.STABLE" => undefined,
> "pbcast.GMS" => undefined,
> "MFC" => undefined,
> "FRAG2" => undefined
> },
> "relay" => undefined,
> "transport" => {
> "TRANSPORT" => undefined,
> "TCP" => undefined
> }
> }> but was:<{
> "protocol" => {
> "MPING" => undefined,
> "MERGE3" => undefined,
> "FD_SOCK" => undefined,
> "VERIFY_SUSPECT" => undefined,
> "pbcast.NAKACK2" => undefined,
> "UNICAST3" => undefined,
> "pbcast.STABLE" => undefined,
> "pbcast.GMS" => undefined,
> "MFC" => undefined,
> "FRAG2" => undefined
> },
> "relay" => undefined,
> "transport" => {
> "TRANSPORT" => undefined,
> "TCP" => undefined
> }
> }>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1630) Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1630?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1630:
-------------------------------------
Description:
When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
{noformat}
[Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
{noformat}
This was observed in a failure of OrderedChildResourcesTestCase.
Failed tests:
OrderedChildResourcesTestCase.testOrderedChildResources:124 expected:<{
"protocol" => {
"MPING" => undefined,
"MERGE3" => undefined,
"FD_SOCK" => undefined,
"FD" => undefined,
"VERIFY_SUSPECT" => undefined,
"pbcast.NAKACK2" => undefined,
"UNICAST3" => undefined,
"pbcast.STABLE" => undefined,
"pbcast.GMS" => undefined,
"MFC" => undefined,
"FRAG2" => undefined
},
"relay" => undefined,
"transport" => {
"TRANSPORT" => undefined,
"TCP" => undefined
}
}> but was:<{
"protocol" => {
"MPING" => undefined,
"MERGE3" => undefined,
"FD_SOCK" => undefined,
"VERIFY_SUSPECT" => undefined,
"pbcast.NAKACK2" => undefined,
"UNICAST3" => undefined,
"pbcast.STABLE" => undefined,
"pbcast.GMS" => undefined,
"MFC" => undefined,
"FRAG2" => undefined
},
"relay" => undefined,
"transport" => {
"TRANSPORT" => undefined,
"TCP" => undefined
}
}>
was:
When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
{noformat}
[Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
[Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
[Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
[Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
[Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
{noformat}
> Ordered resources can fail in domain mode with ava.lang.AssertionError: Unknown operation undefine-attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1630
> URL: https://issues.jboss.org/browse/WFCORE-1630
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.10.Final
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.2.0.CR5, 3.0.0.Alpha3
>
>
> When running in domain mode and using indexed resources, applying of model in domain can fail with assertion error if assertions are enabled.
> {noformat}
> [Host Controller] 16:42:39,979 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 11) WFLYCTL0013: Operation ("apply-remote-domain-model") failed - address: ([]): java.lang.AssertionError: Unknown operation undefine-attribute
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler$OrderedOperationsCollection.add(SyncModelOperationHandler.java:704)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processAttributes(SyncModelOperationHandler.java:203)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:443)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.compareExistsInBothModels(SyncModelOperationHandler.java:446)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processNonOrderedChildrenOfType(SyncModelOperationHandler.java:341)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.processChildren(SyncModelOperationHandler.java:229)
> [Host Controller] at org.jboss.as.domain.controller.operations.SyncModelOperationHandler.execute(SyncModelOperationHandler.java:155)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:409)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.access$1000(DomainModelControllerService.java:179)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1255)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.applyRemoteDomainModel(RemoteDomainConnectionService.java:575)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService.access$1100(RemoteDomainConnectionService.java:131)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnectionService$2.applyDomainModel(RemoteDomainConnectionService.java:518)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection.applyDomainModel(RemoteDomainConnection.java:311)
> [Host Controller] at org.jboss.as.host.controller.RemoteDomainConnection$RegisterSubsystemsRequest$1.execute(RemoteDomainConnection.java:454)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> {noformat}
> This was observed in a failure of OrderedChildResourcesTestCase.
> Failed tests:
> OrderedChildResourcesTestCase.testOrderedChildResources:124 expected:<{
> "protocol" => {
> "MPING" => undefined,
> "MERGE3" => undefined,
> "FD_SOCK" => undefined,
> "FD" => undefined,
> "VERIFY_SUSPECT" => undefined,
> "pbcast.NAKACK2" => undefined,
> "UNICAST3" => undefined,
> "pbcast.STABLE" => undefined,
> "pbcast.GMS" => undefined,
> "MFC" => undefined,
> "FRAG2" => undefined
> },
> "relay" => undefined,
> "transport" => {
> "TRANSPORT" => undefined,
> "TCP" => undefined
> }
> }> but was:<{
> "protocol" => {
> "MPING" => undefined,
> "MERGE3" => undefined,
> "FD_SOCK" => undefined,
> "VERIFY_SUSPECT" => undefined,
> "pbcast.NAKACK2" => undefined,
> "UNICAST3" => undefined,
> "pbcast.STABLE" => undefined,
> "pbcast.GMS" => undefined,
> "MFC" => undefined,
> "FRAG2" => undefined
> },
> "relay" => undefined,
> "transport" => {
> "TRANSPORT" => undefined,
> "TCP" => undefined
> }
> }>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-351) CLI "revert to snapshot" command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-351?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-351:
-----------------------------------------
[~kabirkhan] This is more a question about WFCORE-1052, but I'll ask here as this one is recently active.
What happens in terms of persistence and in terms of :shutdown(restart=true), where the script relaunches the vm passing in the original command line params?
Can the user switch from, say, standalone.xml to standalone-full.xml?
The right behavior re: persistence and script driven restart would probably be different when reloading to a snapshot vs switching the base file.
I'm not sure why someone would switch the base file; perhaps some offline CLI type thing where they are tweaking multiple configs. A corner case.
> CLI "revert to snapshot" command
> --------------------------------
>
> Key: WFCORE-351
> URL: https://issues.jboss.org/browse/WFCORE-351
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: all
> Reporter: Rich Sharples
> Assignee: Kabir Khan
> Labels: eap6-ux
> Fix For: 3.0.0.Alpha1
>
>
> The CLI has commands for taking snapshots, listing snapshots, deleting snapshots but no way to rollback or revert to a previous snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Ali Hopyar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Ali Hopyar commented on JGRP-1914:
----------------------------------
Is there any progress about this issue. We have a bucket in Frankfurt and unfortunately we can not reach it via s3ping :(
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JASSIST-262) Class compilation error - Inconsistent stackmap
by Andrei Ivanov (JIRA)
[ https://issues.jboss.org/browse/JASSIST-262?page=com.atlassian.jira.plugi... ]
Andrei Ivanov commented on JASSIST-262:
---------------------------------------
A release would be nice, if you find a bit of time :)
Thank you
> Class compilation error - Inconsistent stackmap
> -----------------------------------------------
>
> Key: JASSIST-262
> URL: https://issues.jboss.org/browse/JASSIST-262
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: org.javassist:javassist:3.20.0-GA
> java version "1.8.0_74"
> Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)
> Linux 3.13.0-37-generic #64-Ubuntu SMP x86_64 GNU/Linux
> Reporter: Alexey Kuznetsov
> Assignee: Shigeru Chiba
> Fix For: 3.21.0-GA
>
>
> {code:java}
> package com.company;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class Main {
> public static void main(String[] args) {
> CtClass badClass = ClassPool.getDefault().makeClass("badClass");
> String src = String.join(System.getProperty("line.separator"),
> "public void eval () {",
> " if (true) {",
> " double t=0;",
> " } else {",
> " double t=0;",
> " }",
> " for (int i=0; i < 2; i++) {",
> " int a=0;",
> " int b=0;",
> " int c=0;",
> " int d=0;",
> " if (true) {",
> " int e = 0;",
> " }",
> " }",
> "}");
> System.out.println(src);
> try {
> badClass.addMethod(CtMethod.make(src, badClass));
> Class clazzz = badClass.toClass();
> Object obj = clazzz.newInstance(); // <-- falls here
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> After running that i get output:
> {noformat}
> public void eval () {
> if (true) {
> double t=0;
> } else {
> double t=0;
> }
> for (int i=0; i < 2; i++) {
> int a=0;
> int b=0;
> int c=0;
> int d=0;
> if (true) {
> int e = 0;
> }
> }
> }
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 41
> Exception Details:
> Location:
> badClass.eval()V @41: iinc
> Reason:
> Type top (current frame, locals[4]) is not assignable to integer (stack map, locals[4])
> Current Frame:
> bci: @35
> flags: { }
> locals: { 'badClass', top, top, top, top, integer, integer, integer, integer, integer }
> stack: { integer }
> Stackmap Frame:
> bci: @41
> flags: { }
> locals: { 'badClass', top, top, top, integer, integer, integer, integer, integer }
> stack: { }
> Bytecode:
> 0x0000000: 0499 0009 0387 48a7 0006 0387 4a03 3605
> 0x0000010: 1505 05a2 001c 0336 0603 3607 0336 0803
> 0x0000020: 3609 0499 0006 0336 0a84 0501 a7ff e4b1
> 0x0000030:
> Stackmap Table:
> same_frame(@10)
> same_frame(@13)
> full_frame(@16,{Object[#2],Top,Top,Top,Top,Integer},{})
> full_frame(@41,{Object[#2],Top,Top,Top,Integer,Integer,Integer,Integer,Integer},{})
> full_frame(@47,{Object[#2],Top,Top,Top,Top,Integer},{})
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
> at java.lang.Class.getConstructor0(Class.java:3075)
> at java.lang.Class.newInstance(Class.java:412)
> at com.company.Main.main(Main.java:31)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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:140)
> Process finished with exit code 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6123) Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6123?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6123:
---------------------------------
Fix Version/s: 10.1.0.Final
> Infinispan subsystem XSD transaction mode xs:documentation does not list BATCH mode
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6123
> URL: https://issues.jboss.org/browse/WFLY-6123
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Radoslav Husar
> Priority: Trivial
> Fix For: 10.1.0.Final
>
>
> The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says the following about {{<transaction mode="...">}}:
> bq. Sets the cache transaction mode to one of NONE, NON_XA, NON_DURABLE_XA, FULL_XA.
> However, the enum {{org.jboss.as.clustering.infinispan.subsystem.TransactionMode}} has the following values:
> - {{NONE}}
> - {{BATCH}}
> - {{NON_XA}}
> - {{NON_DURABLE_XA}}
> - {{FULL_XA}}
> I.e., the {{BATCH}} value is missing from the documentation. Interestingly, {{BATCH}} is also used in the default config for all the {{web}} and {{ejb}} caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1499:
-------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1349223|https://bugzilla.redhat.com/show_bug.cgi?id=1349223] from ASSIGNED to POST
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1625) Operation description is not complete in :read-resource-description
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1625?page=com.atlassian.jira.plugi... ]
Jeff Mesnil reassigned WFCORE-1625:
-----------------------------------
Assignee: Jeff Mesnil (was: Brian Stansberry)
> Operation description is not complete in :read-resource-description
> -------------------------------------------------------------------
>
> Key: WFCORE-1625
> URL: https://issues.jboss.org/browse/WFCORE-1625
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The ouput of :read-resource-description is missing some metadata for operations compared to :read-operation-description:
> {noformat}
> [domain@localhost:9990 /] /profile=default:read-resource-description(operations=true)
> {
> "outcome" => "success",
> "result" => {
> "description" => "A named set of subsystem configurations.",
> ...
> "operations" => {
> ...
> "read-attribute-group-names" => {
> "operation-name" => "read-attribute-group-names",
> "description" => "Gets the names of all the attribute groups under the selected resource",
> "request-properties" => {},
> "reply-properties" => {
> "type" => LIST,
> "value-type" => STRING
> }
> },
> ...
> }
> [domain@localhost:9990 /] /profile=default:read-operation-description(name=read-attribute-group-names)
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "read-attribute-group-names",
> "description" => "Gets the names of all the attribute groups under the selected resource",
> "request-properties" => {},
> "reply-properties" => {
> "type" => LIST,
> "value-type" => STRING
> },
> "read-only" => true,
> "runtime-only" => true
> }
> }
> {noformat}
> At least read-only and runtime-only metadata are missing (when they are set on the operation).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months