[JBoss JIRA] (WFCORE-413) [cli] exit against remote server fails
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-413?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-1591 to WFCORE-413:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-413 (was: WFLY-1591)
Affects Version/s: (was: 8.0.0.Alpha2)
Component/s: CLI
(was: CLI)
> [cli] exit against remote server fails
> --------------------------------------
>
> Key: WFCORE-413
> URL: https://issues.jboss.org/browse/WFCORE-413
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Rob Stryker
> Assignee: Alexey Loubyansky
> Attachments: WFLY-1591.stack.txt
>
>
> Using ./jboss-cli.sh from a local wildfly alpha2 against a remote wildfly alpha2 connects and functions properly. A call to exit freezes entirely.
> jstack to be attached
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFCORE-409) Intermittent connection TimeOut with CLI using https-remoting
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-409?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3311 to WFCORE-409:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-409 (was: WFLY-3311)
Affects Version/s: (was: 8.1.0.CR1)
Component/s: CLI
(was: CLI)
> Intermittent connection TimeOut with CLI using https-remoting
> -------------------------------------------------------------
>
> Key: WFCORE-409
> URL: https://issues.jboss.org/browse/WFCORE-409
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Filip Bogyai
> Assignee: Alexey Loubyansky
>
> When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time.
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> {code}
> This problem also causes intermittent test failures in testsuite, for example:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-3454 to WFCORE-411:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-411 (was: WFLY-3454)
Component/s: CLI
Patching
(was: CLI)
(was: Patching)
> Syntax error when applying patch and exiting jboss-cli
> ------------------------------------------------------
>
> Key: WFCORE-411
> URL: https://issues.jboss.org/browse/WFCORE-411
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Arun Gupta
> Assignee: Emanuel Muckenhuber
>
> [disconnected /] patch apply
> ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
> {
> "outcome" : "success",
> "result" : {}
> }
> [disconnected /]
> [disconnected /]
> [disconnected /]
> [disconnected /] exit
> logging.configuration already set in JAVA_OPTS
> ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
> ./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-1180) CLI: Embedded Arrays need to be updatable easily
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1180?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1180:
----------------------------------------
This should use the server-side stuff [~ctomc] added to WF9 this summer.
> CLI: Embedded Arrays need to be updatable easily
> ------------------------------------------------
>
> Key: WFLY-1180
> URL: https://issues.jboss.org/browse/WFLY-1180
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jim Tyrrell
> Assignee: Alexey Loubyansky
> Labels: eap6-ux
>
> In the EAP 6 pilot we were presented a long string to create a Database Security Realm, it appears there is no way to update a single value. For example being able to change the string of the SQL of a principalsQuery or rolesQuery for example. Without having to put in the entire vale.
> /profile=default/subsystem=security/security-domain=DB_domain:add(authentication=[{"code" => "Database", "flag" => "required", "module-options"=>[("principalsQuery"=>"Select password from UsersTable.....
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3340:
----------------------------------------
Is this still an issue with latest master? I don't believe it is.
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Alexey Loubyansky
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3340:
-----------------------------------
Component/s: Domain Management
Security
(was: CLI)
> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
> Key: WFLY-3340
> URL: https://issues.jboss.org/browse/WFLY-3340
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management, Security
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: RHEL 6.4, x86_64
> Reporter: Chris Pitman
> Assignee: Alexey Loubyansky
> Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "module-options" => {
> "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
> "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
> "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
> },
> "flag" => "required",
> "code" => "Database"
> }]},
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
> "outcome" => "success",
> "result" => {"login-modules" => [{
> "code" => "Database",
> "flag" => "required",
> "module-options" => [
> ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
> ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
> ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
> ]
> }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-2765) Incremental redeployment (single file update) over management API
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2765?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2765:
-----------------------------------
Component/s: Domain Management
> Incremental redeployment (single file update) over management API
> -----------------------------------------------------------------
>
> Key: WFLY-2765
> URL: https://issues.jboss.org/browse/WFLY-2765
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Ondrej Zizka
> Labels: deploy, deployment, incremental, redeployment
> Fix For: 9.0.0.Beta1
>
>
> (Based on JBDS use case - see EAP6-1)
> See also https://mojo.redhat.com/docs/DOC-934058 for notes
> By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.
> Use cases:
> Big .war's, mainly on remote
> Cloud deployments
> Also, you loose sessions etc.
> "JSP recompile on file update" - mgmt API operation - added in WildFly 8?
> Not expected to work in domain mode.
> Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3166) can't enable datasource both via console or CLI with cluster mode(can't persist to domain.xml)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3166?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3166:
-----------------------------------
Component/s: JCA
(was: ConfigAdmin)
> 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: CLI, 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.8#6338)
9 years, 7 months
[JBoss JIRA] (WFCORE-408) Add a TRACE level category for the operations used to start a server.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-408?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFLY-2256 to WFCORE-408:
-----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-408 (was: WFLY-2256)
Component/s: Domain Management
Logging
(was: Domain Management)
(was: Logging)
Fix Version/s: (was: Awaiting Volunteers)
> Add a TRACE level category for the operations used to start a server.
> ---------------------------------------------------------------------
>
> Key: WFCORE-408
> URL: https://issues.jboss.org/browse/WFCORE-408
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, Logging
> Reporter: Darran Lofthouse
>
> Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server.
> From a development perspective this is useful for double checking the operations are as we expect.
> From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months