[JBoss JIRA] (WFCORE-510) Fix filtering in domain mode
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-510?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet edited comment on WFCORE-510 at 3/6/15 12:24 PM:
-------------------------------------------------------------------
The problem is that the removal of undefined results happens on the operationContext.result and not on the DomainOperationContext.coordinatorResult because the query is done 'against' the servers
was (Author: ehugonnet):
The problem is that the removal of undefined results happens on the operationContext.result and not on the DomainOperationContext.coordinatorResult
> Fix filtering in domain mode
> ----------------------------
>
> Key: WFCORE-510
> URL: https://issues.jboss.org/browse/WFCORE-510
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Harald Pehl
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> The overall result for query operations in domain mode does not filter undefined results. Executing the following operation, will yield three results. However the last result needs to be filtered:
> {code}
> [domain@localhost:9990 /] /host=master/server-config=*:query(select=[name, status, auto-start], where={auto-start=>true})
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-one")
> ],
> "outcome" => undefined,
> "result" => {
> "name" => "server-one",
> "status" => "STARTED",
> "auto-start" => true
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-two")
> ],
> "outcome" => undefined,
> "result" => {
> "name" => "server-two",
> "status" => "STARTED",
> "auto-start" => true
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-three")
> ],
> "outcome" => undefined,
> "result" => undefined
> }
> ],
> "server-groups" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-510) Fix filtering in domain mode
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-510?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-510:
------------------------------------------
The problem is that the removal of undefined results happens on the operationContext.result and not on the DomainOperationContext.coordinatorResult
> Fix filtering in domain mode
> ----------------------------
>
> Key: WFCORE-510
> URL: https://issues.jboss.org/browse/WFCORE-510
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Harald Pehl
> Assignee: ehsavoie Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> The overall result for query operations in domain mode does not filter undefined results. Executing the following operation, will yield three results. However the last result needs to be filtered:
> {code}
> [domain@localhost:9990 /] /host=master/server-config=*:query(select=[name, status, auto-start], where={auto-start=>true})
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-one")
> ],
> "outcome" => undefined,
> "result" => {
> "name" => "server-one",
> "status" => "STARTED",
> "auto-start" => true
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-two")
> ],
> "outcome" => undefined,
> "result" => {
> "name" => "server-two",
> "status" => "STARTED",
> "auto-start" => true
> }
> },
> {
> "address" => [
> ("host" => "master"),
> ("server-config" => "server-three")
> ],
> "outcome" => undefined,
> "result" => undefined
> }
> ],
> "server-groups" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-586) domain controller does not timeout on bad app deploy
by Ian Kent (JIRA)
Ian Kent created WFCORE-586:
-------------------------------
Summary: domain controller does not timeout on bad app deploy
Key: WFCORE-586
URL: https://issues.jboss.org/browse/WFCORE-586
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Environment: WF 8.2.0-FINAL
Reporter: Ian Kent
Assignee: Brian Stansberry
We have a WildFly domain setup with 5 server groups and at least one server in each group. We continuous deploy applications (wars) into the domain from out continuos integration/deployment tool (Bamboo) using the WildFly CLI.
{noformat}
jboss-cli --connect --controller=host:port --timeout=10000 --command="deploy x.war --name=x.war --runtime-name=x-version.war --server-groups=A"
{noformat}
If an app has trouble deploying due to looping on resource connection attempts it blocks the bamboo agent and domain controller for undetermined amount of time.
I know there is a connection timeout, but what about a deployment timeout?
If a deploy does not finish within timeout then it it cancelled.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFLY-3166) can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
by Claudio Pellizzari (JIRA)
[ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.... ]
Claudio Pellizzari commented on WFLY-3166:
------------------------------------------
I don't understand where it is possible to display the steps to solve the issue, can anybody point me in the page containing the solution?
> can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3166
> URL: https://issues.jboss.org/browse/WFLY-3166
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Web Console
> Affects Versions: 8.0.0.Final
> Environment: Red Hat Enterprise Linux Server release 5.5
> Reporter: Fai Gao
> Assignee: Stefano Maestri
>
> Create a MySQL datasource via CLI:
> /profile=front-ha/subsystem=datasources/data-source=testmysql:add(driver-name=com.mysql,jndi-name=java:jboss/datasources/mysql,connection-url=jdbc:mysql://192.168.1.100:3306/udmp,max-pool-size=100,min-pool-size=10,user-name=aaaa,password=bbbb,enabled=false)
> And then enable it via console,but the lable of enabled didn't turn to √(enabled).
> Check the domain.xml,the value of enabled is still false.
> Enable it again whether via CLI or console,error log print:
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
> "rolled-back" => true,
> "server-groups" => {"front-group1" => {"host" => {"master" => {"fserver1" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: Service jboss.data-source-config.testmysql is already registered",
> "rolled-back" => true
> }}}}}}
> }
> [Server:fserver1] 16:45:48,888 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 10) JBAS014612: Operation ("enable") failed - address: ([
> [Server:fserver1] ("subsystem" => "datasources"),
> [Server:fserver1] ("data-source" => "testmysql")
> [Server:fserver1] ]): org.jboss.msc.service.DuplicateServiceException: Service jboss.data-source-config.testmysql is already registered
> [Server:fserver1] at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
> [Server:fserver1] at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:1418) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:188)
> [Server:fserver1] at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:84)
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:179) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:149) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:113) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:83) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:129) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:125) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.0.Final.jar:8.0.0.Final]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> [Server:fserver1] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> [Server:fserver1] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> [Server:fserver1]
> I tried in the standalone mode,it worked.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-585:
---------------------------------------
Summary: Offline CLI for a Host Controller
Key: WFCORE-585
URL: https://issues.jboss.org/browse/WFCORE-585
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management
Reporter: Brian Stansberry
Fix For: 2.0.0.Alpha1
Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server.
This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-584) Offline CLI for a standalone server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-584?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-584:
------------------------------------
Description:
Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
This JIRA is for administering a standalone server. A separate JIRA (WFCORE-585) has been filed for equivalent functionality for a Host Controller.
was:
Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
This JIRA is for administering a standalone server. A separate JIRA will be filed for equivalent functionality for a Host Controller.
> Offline CLI for a standalone server
> -----------------------------------
>
> Key: WFCORE-584
> URL: https://issues.jboss.org/browse/WFCORE-584
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
>
> As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
> This JIRA is for administering a standalone server. A separate JIRA (WFCORE-585) has been filed for equivalent functionality for a Host Controller.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (WFCORE-584) Offline CLI for a standalone server
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-584:
---------------------------------------
Summary: Offline CLI for a standalone server
Key: WFCORE-584
URL: https://issues.jboss.org/browse/WFCORE-584
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.Beta1
Direct local administration of a standalone server running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999.
As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool.
This JIRA is for administering a standalone server. A separate JIRA will be filed for equivalent functionality for a Host Controller.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGTOOL-71:
---------------------------------
Fix Version/s: 1.2.2.Final
(was: 1.2.1.Final)
> Allow messages to have expressions resolved at code generation time
> -------------------------------------------------------------------
>
> Key: LOGTOOL-71
> URL: https://issues.jboss.org/browse/LOGTOOL-71
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.2.2.Final
>
>
> Allow messages in the {{@Message}} annotation to allow expressions in the format of:
> {code}
> ${property.name:default}
> {code}
> A warning message should be generated if the property name was not found. If not default is found an error should be generated.
> The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months