bserdar / jcliff Goto Github PK
View Code? Open in Web Editor NEWManage JBossAS 7/EAP6/Wildfly with modular configuration files from command line, puppet, ansible, chef, etc.
License: Other
Manage JBossAS 7/EAP6/Wildfly with modular configuration files from command line, puppet, ansible, chef, etc.
License: Other
Kind of noisey output in a system with lots of configuration items, i.e., you see many many lines of output similar to this:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:add:/xadatasource/esbebs/xa-datasource-properties/URL/value => "jdbc:oracle:oci:@ebs"
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:add:/xadatasource/esbsso/xa-datasource-properties/URL/value => "jdbc:oracle:oci:@web"
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:add:/xadatasource/vendorregnum/xa-datasource-properties/URL/value => "jdbc:oracle:oci:@web"
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:add:/xadatasource/webcustomersite/xa-datasource-properties/URL/value => "jdbc:oracle:oci:@web"
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:modify:/webservices/wsdl-host => "jbossws.undefined.host"(/webservices/wsdl-host => expression "${jboss.bind.address:127.0.0.1}")
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns:
notice: /Stage[main]/Libeap6::Jcliff/Exec[configure-eap6]/returns: No rules for diffs:add:/deployments/activation-service-ear-2.10.0.eap6.ear/path => "/var/lib/redhat/services/deploy/activation-service-ear-2.10.0.eap6.ear"
I see the debugging value for this kind of output during development and initial deployment, but in a production environment it would nice if NOOPs were silent.
Unfortunately, it's not working when we use jcliff like this to deploy a jdbc driver and an app (.war) that depends on the driver:
/usr/bin/jcliff --cli=/opt/wildfly/bin/jboss-cli.sh \
--controller=127.0.0.1:9990 --user=mgmt-users --password=very-secret-password \
--reload /etc/jcliff/* -v
The reload happens at the end of the jcliff run, which fails the deployment of the app.
We do somehow expect following sequence: driver --> reload --> deploy app.
Do you know if this is a bug in jcliff? Thanks.
Make something like this manageable by JCliff:
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=BlaSMTP:add(host=localhost, port=25)
/subsystem=mail/mail-session=BlaMail:add(jndi-name="java:jboss/mail/Bla", from="[email protected]", debug=false)
/subsystem=mail/mail-session=BlaMail/server=smtp:add(outbound-socket-binding-ref=BlaSMTP, ssl=false)
When being used with WildFly, of course user/group jboss don't exist.
warning: user jboss does not exist - using root
warning: group jboss does not exist - using root
In such a case, the rpm could use the wildfly user and group instead.
...or, write a script that'll generate that from the rules.
When I try to set "proxy-address-forwarding" to "true" for the default http-listener, I get this:
No rules for diffs:add:/subsystem/undertow/server/default-server/http-listener value={"default" => {"proxy-address-forwarding" => "true"}}
add:/subsystem/undertow/server/default-server/http-listener/default value={"proxy-address-forwarding" => "true"}
add:/subsystem/undertow/server/default-server/http-listener/default/proxy-address-forwarding value="true"
In a running JBoss Domain environment (as opposed to a Standalone environment), configuration changes and deployments are done on the one and only Host Controller (HC) designated as the Domain Controller (DC). When using the JBoss CLI to perform a configuration change on a specific host, I have to talk to the DC and specify /host= in front of e. g. /subsystem=. Similarly, to deploy content onto a particular group of servers, I have to specify /server-group= in front of /deployment=, etc.
How can I tell JCliff to which HC (/host=) or to which Server Group (/server-group=) to address a change or deployment, respectively? These two nodes are currently not accepted by JCliff in Input files and I couldn't find them in any rules either. Are there other mechanisms to achieve this?
Cheers,
Heinz
The following JSON block will not be processed, as the web rule does not contain the rules for "rewrite"
{
"web" => {
"virtual-server" => {"default-host" => {
"alias" => ["localhost","test"],
"default-web-module" => "ROOT.war",
"enable-welcome-root" => false,
"name" => "default-host",
"access-log" => undefined,
"configuration" => undefined,
"rewrite" => {"rule-titiserverversion" => {
"flags" => "L",
"pattern" => "^/titiserver/rest/(.*)$",
"substitution" => "/titiserver/v0.0.5/rest/$1",
"condition" => undefined
}},
"sso" => undefined
}}
}
}
On every Puppet run (30 min) the server state changes from "running" to "reload-required" due to the datasource jcliff file. By removing the line '"enabled" => "true"' this strange behavior stops.
Is it possible to implement a Java check that verifies the enable parameter ? Could you try to reproduce this ?
{
"datasource" => {
"TokenServerDS" => {
"jndi-name" => "java:jboss/datasources/TitiServerDS",
"connection-url" => "jdbc:postgresql://localhost:5432/titiserver",
"driver-name" => "PostgresDriver",
"user-name" => "postgres",
"password" => "postgres",
"enabled" => "true",
}
}
}
There is no rule to modify attributes for the remoting connector under subsystem, especially the 'security-realm' attribute:
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
Can you please add a rule ?
Whilst I fear I'm going to sound like a complete numpty, could you let me know what file you're meant to pass as an argument? From the readme it sounded like it was the .pp files and as such I passed the sample datasource.pp from your project but when I do that I get:
(as you can probably tell I'm no Java expert)
Thanks in advance and great project by the way!
Exception in thread "main" java.io.IOException: Invalid character: d
at org.jboss.dmr.ModelNodeParser.invalid(ModelNodeParser.java:162)
at org.jboss.dmr.Parser.yyLex(Parser.java:617)
at org.jboss.dmr.Parser.yyParse(Parser.java:683)
at org.jboss.dmr.ModelNode.fromStream(ModelNode.java:1314)
at com.redhat.jcliff.Main.main(Main.java:164)
In Wildfly 9 the offline mode was introduced for CLI commands. Will JCliff support this way of constructing the standalone.xml ?
https://developer.jboss.org/wiki/OfflineCLIWork
https://access.redhat.com/solutions/1426123#
It would be nice to be able to add the slot capability to drivers. Using module /org/postgresql/9.2/module.xml for example.
This is how you add a driver today :
{ "jdbc-driver" =>
{ "PostgresDriver" => {
"driver-name" => "PostgresDriver",
"driver-module-name" => "org.postgresql",
"driver-xa-datasource-class-name" => "org.postgresql.xa.PGXADataSource",
}
}
}
this will use /org/postgresql/main/module.xml
This is what be nice to have :
{ "jdbc-driver" =>
{ "PostgresDriver" => {
"driver-name" => "PostgresDriver",
"driver-module-name" => "org.postgresql",
"driver-xa-datasource-class-name" => "org.postgresql.xa.PGXADataSource",
"module-slot" = "9.2"
}
}
}
this will use /org/postgresql/9.2/module.xml
--> the first line of module.xml
I'm trying to add
<gzip name="gzipFilter"/>
under the filters section of undertow.
This is my jcliff template:
{ "undertow" =>
{ "configuration" =>
{ "filter" =>
{ "gzip" =>
{ "name" => "gzipFilter" }
}
}
}
}
But the result is: No rules for diffs:add:/configuration/filter/gzip/name value="gzipFilter".
Could you please add the necessary rules?
Sometimes (about once out of four tries), jcliff doesn't wait for WildFly long enough after reloading it.
This is the verbose jcliff log:
...
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=blocking-timeout-wait-millis,value="1000")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=idle-timeout-minutes,value="5")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=query-timeout,value="0")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=set-tx-query-timeout,value="false")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=share-prepared-statements,value="false")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=use-try-lock,value="0")
2015-10-27 13:46:48:0398: cmds:/subsystem=datasources/data-source=PasseportWriteDS:write-attribute(name=validate-on-match,value="true")
2015-10-27 13:46:48:0398: cmds:run-batch
2015-10-27 13:46:48:0398: Script file:/tmp/jcliff-script2373698895087090811.tmp true
2015-10-27 13:46:48:0398: In file:/tmp/jcliff-in2076208699409391012.tmp true
2015-10-27 13:46:49:0564: return Code has :0
2015-10-27 13:46:49:0568: stderr:
2015-10-27 13:46:49:0568: stdout:The batch executed successfully
process-state: reload-required
2015-10-27 13:46:49:0568: Return:The batch executed successfully
process-state: reload-required
2015-10-27 13:46:49:0569: in file:/tmp/jcliff-in2216300268130915430.tmp true
2015-10-27 13:46:49:0569: out file:/tmp/jcliff-out2224194031294791864.tmp true
2015-10-27 13:46:49:0569: err file:/tmp/jcliff-err3305043549566407063.tmp true
2015-10-27 13:46:49:0569: script file:/tmp/jcliff-script6048437213908135456.tmp true
2015-10-27 13:46:49:0569: args:/opt/wildfly/bin/jboss-cli.sh
2015-10-27 13:46:49:0569: args:--controller=127.0.0.1:9990
2015-10-27 13:46:49:0569: args:--connect
2015-10-27 13:46:49:0569: args:--file=/tmp/jcliff-in2216300268130915430.tmp
2015-10-27 13:46:49:0569: args:--user=admin-myhostname
2015-10-27 13:46:49:0569: args:--password=*****
2015-10-27 13:46:49:0569: args:--timeout=5000
2015-10-27 13:46:49:0569: cmds:ls
2015-10-27 13:46:49:0569: Script file:/tmp/jcliff-script6048437213908135456.tmp true
2015-10-27 13:46:49:0569: In file:/tmp/jcliff-in2216300268130915430.tmp true
2015-10-27 13:46:50:0679: return Code has :0
2015-10-27 13:46:50:0679: stderr:
2015-10-27 13:46:50:0679: stdout:core-service
deployment
deployment-overlay
extension
interface
path
socket-binding-group
subsystem
system-property
launch-type=STANDALONE
management-major-version=2
management-micro-version=0
management-minor-version=2
name=myhostname
namespaces=[]
process-type=Server
product-name=undefined
product-version=undefined
profile-name=undefined
release-codename=Tweek
release-version=8.2.0.Final
running-mode=NORMAL
schema-locations=[]
server-state=reload-required
2015-10-27 13:46:50:0679: Return:core-service
deployment
deployment-overlay
extension
interface
path
socket-binding-group
subsystem
system-property
launch-type=STANDALONE
management-major-version=2
management-micro-version=0
management-minor-version=2
name=myhostname
namespaces=[]
process-type=Server
product-name=undefined
product-version=undefined
profile-name=undefined
release-codename=Tweek
release-version=8.2.0.Final
running-mode=NORMAL
schema-locations=[]
server-state=reload-required
2015-10-27 13:46:50:0680: in file:/tmp/jcliff-in2920145061752891963.tmp true
2015-10-27 13:46:50:0680: out file:/tmp/jcliff-out3146731002401624511.tmp true
2015-10-27 13:46:50:0680: err file:/tmp/jcliff-err2672618051574195629.tmp true
2015-10-27 13:46:50:0680: script file:/tmp/jcliff-script2630814811893108199.tmp true
2015-10-27 13:46:50:0680: args:/opt/wildfly/bin/jboss-cli.sh
2015-10-27 13:46:50:0680: args:--controller=127.0.0.1:9990
2015-10-27 13:46:50:0680: args:--connect
2015-10-27 13:46:50:0680: args:--file=/tmp/jcliff-in2920145061752891963.tmp
2015-10-27 13:46:50:0680: args:--user=admin-myhostname
2015-10-27 13:46:50:0680: args:--password=*****
2015-10-27 13:46:50:0680: args:--timeout=5000
2015-10-27 13:46:50:0680: cmds::reload
2015-10-27 13:46:50:0680: Script file:/tmp/jcliff-script2630814811893108199.tmp true
2015-10-27 13:46:50:0680: In file:/tmp/jcliff-in2920145061752891963.tmp true
2015-10-27 13:46:51:0922: return Code has :0
2015-10-27 13:46:51:0922: stderr:
2015-10-27 13:46:51:0922: stdout:{
"outcome" => "success",
"result" => undefined
}
2015-10-27 13:46:51:0922: Return:{
"outcome" => "success",
"result" => undefined
}
2015-10-27 13:46:51:0923: in file:/tmp/jcliff-in3244564751908510918.tmp true
2015-10-27 13:46:51:0923: out file:/tmp/jcliff-out7030680984186590786.tmp true
2015-10-27 13:46:51:0923: err file:/tmp/jcliff-err9033155621287357853.tmp true
2015-10-27 13:46:51:0923: script file:/tmp/jcliff-script5147996763721763743.tmp true
2015-10-27 13:46:51:0923: args:/opt/wildfly/bin/jboss-cli.sh
2015-10-27 13:46:51:0923: args:--controller=127.0.0.1:9990
2015-10-27 13:46:51:0923: args:--connect
2015-10-27 13:46:51:0923: args:--file=/tmp/jcliff-in3244564751908510918.tmp
2015-10-27 13:46:51:0923: args:--user=admin-myhostname
2015-10-27 13:46:51:0923: args:--password=*****
2015-10-27 13:46:51:0923: args:--timeout=5000
2015-10-27 13:46:51:0923: cmds:ls
2015-10-27 13:46:51:0923: Script file:/tmp/jcliff-script5147996763721763743.tmp true
2015-10-27 13:46:51:0923: In file:/tmp/jcliff-in3244564751908510918.tmp true
2015-10-27 13:46:54:0254: return Code has :0
2015-10-27 13:46:54:0255: stderr:
2015-10-27 13:46:54:0255: stdout:core-service
deployment
deployment-overlay
extension
interface
path
socket-binding-group
subsystem
system-property
launch-type=STANDALONE
management-major-version=2
management-micro-version=0
management-minor-version=2
name=myhostname
namespaces=[]
process-type=Server
product-name=undefined
product-version=undefined
profile-name=undefined
release-codename=Tweek
release-version=8.2.0.Final
running-mode=NORMAL
schema-locations=[]
server-state=starting
2015-10-27 13:46:54:0255: Return:core-service
deployment
deployment-overlay
extension
interface
path
socket-binding-group
subsystem
system-property
launch-type=STANDALONE
management-major-version=2
management-micro-version=0
management-minor-version=2
name=myhostname
namespaces=[]
process-type=Server
product-name=undefined
product-version=undefined
profile-name=undefined
release-codename=Tweek
release-version=8.2.0.Final
running-mode=NORMAL
schema-locations=[]
server-state=starting
2015-10-27 13:46:54:0256: in file:/tmp/jcliff-in8261434089074670813.tmp true
2015-10-27 13:46:54:0256: out file:/tmp/jcliff-out2921501971237476451.tmp true
2015-10-27 13:46:54:0256: err file:/tmp/jcliff-err1345454118171290641.tmp true
2015-10-27 13:46:54:0256: script file:/tmp/jcliff-script5533378880105915110.tmp true
2015-10-27 13:46:54:0256: args:/opt/wildfly/bin/jboss-cli.sh
2015-10-27 13:46:54:0256: args:--controller=127.0.0.1:9990
2015-10-27 13:46:54:0256: args:--connect
2015-10-27 13:46:54:0256: args:--file=/tmp/jcliff-in8261434089074670813.tmp
2015-10-27 13:46:54:0256: args:--user=admin-myhostname
2015-10-27 13:46:54:0256: args:--password=*****
2015-10-27 13:46:54:0256: args:--timeout=5000
2015-10-27 13:46:54:0256: cmds:ls
2015-10-27 13:46:54:0256: Script file:/tmp/jcliff-script5533378880105915110.tmp true
2015-10-27 13:46:54:0256: In file:/tmp/jcliff-in8261434089074670813.tmp true
2015-10-27 13:47:06:0785: return Code has :1
2015-10-27 13:47:06:0793: stderr: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:235)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
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:483)
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 127.0.0.1:9990
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 http-remoting://127.0.0.1:9990. 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 http-remoting://127.0.0.1:9990. 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
2015-10-27 13:47:06:0793: stdout:
2015-10-27 13:47:06:0813: java.lang.RuntimeException: java.lang.RuntimeException: 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:235)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
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:483)
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 127.0.0.1:9990
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 http-remoting://127.0.0.1:9990. 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 http-remoting://127.0.0.1:9990. 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
at com.redhat.jcliff.Cli.run(Cli.java:193)
at com.redhat.jcliff.Cli.run(Cli.java:105)
at com.redhat.jcliff.Cli.run(Cli.java:60)
at com.redhat.jcliff.Main.reloadRequired(Main.java:322)
at com.redhat.jcliff.Main.main(Main.java:254)
Caused by: java.lang.RuntimeException: 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:235)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
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:483)
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 127.0.0.1:9990
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 http-remoting://127.0.0.1:9990. 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 http-remoting://127.0.0.1:9990. 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
at com.redhat.jcliff.Cli.run(Cli.java:184)
... 4 more
==> /var/log/messages <==
Oct 27 13:47:07 myhostname puppet-agent[2545]: (/Stage[main]/Wildfly::Jcliff::Execution/Exec[wildfly-jcliff-execution]) Failed to call refresh: /usr/bin/jcliff --cli=/opt/wildfly/bin/jboss-cli.sh -v -- controller=127.0.0.1:9990 --output=/var/log/jcliff/jcliff.log --reload --user=admin-myhostname --password=***** /etc/jcliff/* returned 1 instead of one of [0]
Oct 27 13:47:07 myhostname puppet-agent[2545]: (/Stage[main]/Wildfly::Jcliff::Execution/Exec[wildfly-jcliff-execution]) /usr/bin/jcliff --cli=/opt/wildfly/bin/jboss-cli.sh -v --controller=127.0.0.1:9990 -- output=/var/log/jcliff/jcliff.log --reload --user=admin-myhostname --password=***** /etc/jcliff/* returned 1 instead of one of [0]
Oct 27 13:47:07 myhostname puppet-agent[2545]: Finished catalog run in 59.95 seconds
WildFly was back available at 2015-10-27 13:47:11,424:
INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 18730ms - Started 491 of 676 services (273 services are lazy, passive or on-demand)
Summary:
2015-10-27 13:46:50:0680: cmds::reload
2015-10-27 13:47:06:0793: stderr:org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
2015-10-27 13:47:11,424 WildFly is available again
Shouldn't jcliff wait at least 5 seconds (args:--timeout=5000)?
Using the deleted value to remove an entry from jboss generally works, but not in all cases, eg:
{
"remoting" => {
"connector" => {"remoting-connector" => {
"security-realm" => "deleted",
}},
}
}
I have also tried
{
"remoting" => {
"connector" => {"remoting-connector" => {
"security-realm" => undefined,
}},
}
}
[standalone@XXX:9999 /] /subsystem=remoting/connector=remoting-connector:read-resource
{
"outcome" => "success",
"result" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}
}
jcliff log:
2016-03-23 14:39:16:0532: Opening /opt/jboss1/jcliff_config/foo.conf
2016-03-23 14:39:16:0550: Processing remoting
2016-03-23 14:39:16:0550: Reading current status of remoting
2016-03-23 14:39:16:0550: /subsystem=remoting:read-resource(recursive=true)
2016-03-23 14:39:16:0564: in file:/tmp/jcliff-in8123541853270804807.tmp true
2016-03-23 14:39:16:0565: out file:/tmp/jcliff-out7347759627314159157.tmp true
2016-03-23 14:39:16:0565: err file:/tmp/jcliff-err6181094857491009912.tmp true
2016-03-23 14:39:16:0565: script file:/tmp/jcliff-script7640875743618752113.tmp true
2016-03-23 14:39:16:0565: args:/opt/jboss1/jboss/bin/jboss-cli.sh
2016-03-23 14:39:16:0565: args:--controller=XXX:9999
2016-03-23 14:39:16:0565: args:--connect
2016-03-23 14:39:16:0565: args:--file=/tmp/jcliff-in8123541853270804807.tmp
2016-03-23 14:39:16:0565: args:--timeout=5000
2016-03-23 14:39:16:0566: cmds:/subsystem=remoting:read-resource(recursive=true)
2016-03-23 14:39:16:0566: Script file:/tmp/jcliff-script7640875743618752113.tmp true
2016-03-23 14:39:16:0566: In file:/tmp/jcliff-in8123541853270804807.tmp true
2016-03-23 14:39:17:0589: return Code has :0
2016-03-23 14:39:17:0591: stderr:
2016-03-23 14:39:17:0591: stdout:{
"outcome" => "success",
"result" => {
"worker-read-threads" => 1,
"worker-task-core-threads" => 4,
"worker-task-keepalive" => 60,
"worker-task-limit" => 16384,
"worker-task-max-threads" => 16,
"worker-write-threads" => 1,
"connector" => {"remoting-connector" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}},
"local-outbound-connection" => undefined,
"outbound-connection" => undefined,
"remote-outbound-connection" => undefined
}
}
2016-03-23 14:39:17:0591: Return:{
"outcome" => "success",
"result" => {
"worker-read-threads" => 1,
"worker-task-core-threads" => 4,
"worker-task-keepalive" => 60,
"worker-task-limit" => 16384,
"worker-task-max-threads" => 16,
"worker-write-threads" => 1,
"connector" => {"remoting-connector" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}},
"local-outbound-connection" => undefined,
"outbound-connection" => undefined,
"remote-outbound-connection" => undefined
}
}
2016-03-23 14:39:17:0595: Node from server:{
"worker-read-threads" => 1,
"worker-task-core-threads" => 4,
"worker-task-keepalive" => 60,
"worker-task-limit" => 16384,
"worker-task-max-threads" => 16,
"worker-write-threads" => 1,
"connector" => {"remoting-connector" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}},
"local-outbound-connection" => undefined,
"outbound-connection" => undefined,
"remote-outbound-connection" => undefined
}
2016-03-23 14:39:17:0596: After preprocessing:{
"worker-read-threads" => 1,
"worker-task-core-threads" => 4,
"worker-task-keepalive" => 60,
"worker-task-limit" => 16384,
"worker-task-max-threads" => 16,
"worker-write-threads" => 1,
"connector" => {"remoting-connector" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}},
"local-outbound-connection" => undefined,
"outbound-connection" => undefined,
"remote-outbound-connection" => undefined
}
2016-03-23 14:39:17:0596: Configuration node after preprocessing:{"connector" => {"remoting-connector" => {"security-realm" => "deleted"}}}
2016-03-23 14:39:17:0598: computeDiff
2016-03-23 14:39:17:0598: Config path:/connector value={"remoting-connector" => {"security-realm" => "deleted"}}
2016-03-23 14:39:17:0599: Config path:/connector/remoting-connector value={"security-realm" => "deleted"}
2016-03-23 14:39:17:0599: Config path:/connector/remoting-connector/security-realm value="deleted"
2016-03-23 14:39:17:0599: Server path:/worker-read-threads value=1
2016-03-23 14:39:17:0599: Server path:/worker-task-core-threads value=4
2016-03-23 14:39:17:0599: Server path:/worker-task-keepalive value=60
2016-03-23 14:39:17:0599: Server path:/worker-task-limit value=16384
2016-03-23 14:39:17:0599: Server path:/worker-task-max-threads value=16
2016-03-23 14:39:17:0599: Server path:/worker-write-threads value=1
2016-03-23 14:39:17:0600: Server path:/connector value={"remoting-connector" => {
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}}
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector value={
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
}
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/authentication-provider value=undefined
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/sasl-protocol value="remote"
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/security-realm value="ApplicationRealm"
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/server-name value=undefined
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/socket-binding value="remoting"
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/property value=undefined
2016-03-23 14:39:17:0600: Server path:/connector/remoting-connector/security value=undefined
2016-03-23 14:39:17:0600: Server path:/local-outbound-connection value=undefined
2016-03-23 14:39:17:0600: Server path:/outbound-connection value=undefined
2016-03-23 14:39:17:0601: Server path:/remote-outbound-connection value=undefined
2016-03-23 14:39:17:0601: Processing path /connector:OBJECT
2016-03-23 14:39:17:0601: Comparing for reorder: /connector cfg:[remoting-connector] s:[remoting-connector]
2016-03-23 14:39:17:0601: Processing path /connector/remoting-connector:OBJECT
2016-03-23 14:39:17:0601: Comparing for reorder: /connector/remoting-connector cfg:[security-realm] s:[authentication-provider, sasl-protocol, security-realm, server-name, socket-binding, property, security]
2016-03-23 14:39:17:0602: Processing path /connector/remoting-connector/security-realm:STRING
2016-03-23 14:39:17:0602: Node deleted
2016-03-23 14:39:17:0602: Diff:remove:/connector/remoting-connector/security-realm value="deleted"
2016-03-23 14:39:17:0602: Diff:reorder:/connector/remoting-connector value={"security-realm" => "deleted"}(/connector/remoting-connector value={
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
})
2016-03-23 14:39:17:0604: Checking rule modProps
2016-03-23 14:39:17:0604: Checking rule addHttpConnector
2016-03-23 14:39:17:0604: Checking rule removeOutboundConnection
2016-03-23 14:39:17:0604: Checking rule removeConnector
2016-03-23 14:39:17:0604: Checking rule removeHttpConnector
2016-03-23 14:39:17:0605: Checking rule removeRemoteOutboundConnection
2016-03-23 14:39:17:0605: Checking rule removeLocalOutboundConnection
2016-03-23 14:39:17:0605: Checking rule addConnector
2016-03-23 14:39:17:0605: Checking rule addRemoteOutboundConnection
2016-03-23 14:39:17:0605: Checking rule addLocalOutboundConnection
2016-03-23 14:39:17:0605: Checking rule addOutboundConnection
2016-03-23 14:39:17:0605: Checking rule modOutboundConnection
2016-03-23 14:39:17:0605: Checking rule modHttpConnector
2016-03-23 14:39:17:0605: Checking rule modLocalOutboundConnection
2016-03-23 14:39:17:0605: Checking rule modConnector
2016-03-23 14:39:17:0605: Checking rule configEndpointProps
2016-03-23 14:39:17:0605: Checking rule modRemoteOutboundConnection
2016-03-23 14:39:17:0605: No rules for diffs:remove:/connector/remoting-connector/security-realm value="deleted"
reorder:/connector/remoting-connector value={"security-realm" => "deleted"}(/connector/remoting-connector value={
"authentication-provider" => undefined,
"sasl-protocol" => "remote",
"security-realm" => "ApplicationRealm",
"server-name" => undefined,
"socket-binding" => "remoting",
"property" => undefined,
"security" => undefined
})
2016-03-23 14:39:17:0605: Processing deployments
2016-03-23 14:39:17:0606: All requested deployments:{}
Despite jcliff 2.9.11 running JBoss CLI in batch mode, wildfly 8.2.0.Final refused adding a XA datasource with
Exception in thread "main" java.lang.RuntimeException: Operation failed:{"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS010469: At least one xa-datasource-property
is required for an xa-datasource"}}
Using this in /usr/share/jcliff-2.9.11/rules/xadatasource
works:
add.rule.1=xa-data-source add --name=${name(.)} --jndi-name=${value(jndi-name)} --driver-name=${value(driver-name)} --xa-datasource-properties=[{URL=${value(xa-datasource-properties/URL/value)}}]
add.rule.2=if result.value==false of /subsystem=datasources/xa-datasource=${name(.)}:read-resource
add.rule.3=xa-data-source enable --name=${name(.)}
There is no way to undeploy an app.
When changing driver-module-name between two JCliff runs, "No rules for diffs:modify" is thrown.
{ "jdbc-driver" =>
{ "<%= @drivernamever %>" => {
"driver-name" => "<%= @drivernamever %>",
"driver-module-name" => "<%= @driver_module_name %>",
"driver-xa-datasource-class-name" => "<%= @driver_xa_datasource_class_name %>"
}
}
}
I want to add a global-module attribute in ee subsystem. The following exception is raised:
Setting ruledir to:/usr/share/jcliff-2.10.2/rules
Reading properties from file: /usr/share/jcliff-2.10.2/rules/rules
Reading properties from file: /usr/share/jcliff-2.10.2/rules/system-properties
Reading properties from file: /usr/share/jcliff-2.10.2/rules/path
Reading properties from file: /usr/share/jcliff-2.10.2/rules/ee
Reading properties from file: /usr/share/jcliff-2.10.2/rules/jmx
Reading properties from file: /usr/share/jcliff-2.10.2/rules/naming
Reading properties from file: /usr/share/jcliff-2.10.2/rules/threads
Reading properties from file: /usr/share/jcliff-2.10.2/rules/logging
Reading properties from file: /usr/share/jcliff-2.10.2/rules/jdbc-driver
Reading properties from file: /usr/share/jcliff-2.10.2/rules/security
Reading properties from file: /usr/share/jcliff-2.10.2/rules/datasource
Reading properties from file: /usr/share/jcliff-2.10.2/rules/xadatasource
Reading properties from file: /usr/share/jcliff-2.10.2/rules/standard-sockets
Reading properties from file: /usr/share/jcliff-2.10.2/rules/security-realms
Reading properties from file: /usr/share/jcliff-2.10.2/rules/web
Reading properties from file: /usr/share/jcliff-2.10.2/rules/webservices
Reading properties from file: /usr/share/jcliff-2.10.2/rules/jgroups
Reading properties from file: /usr/share/jcliff-2.10.2/rules/infinispan
Reading properties from file: /usr/share/jcliff-2.10.2/rules/scanner
Reading properties from file: /usr/share/jcliff-2.10.2/rules/subsystem
Reading properties from file: /usr/share/jcliff-2.10.2/rules/remoting
Reading properties from file: /usr/share/jcliff-2.10.2/rules/osgi
Reading properties from file: /usr/share/jcliff-2.10.2/rules/messaging
Reading properties from file: /usr/share/jcliff-2.10.2/rules/mail
Reading properties from file: /usr/share/jcliff-2.10.2/rules/ejb3
Reading properties from file: /usr/share/jcliff-2.10.2/rules/resource-adapter
Reading properties from file: /usr/share/jcliff-2.10.2/rules/transactions
Reading properties from file: /usr/share/jcliff-2.10.2/rules/undertow
Reading properties from file: /usr/share/jcliff-2.10.2/rules/teiid
Reading properties from file: /usr/share/jcliff-2.10.2/rules/rbac
Exception in thread "main" java.lang.RuntimeException: Expected one result, got 0 for ${path(..)}
at com.redhat.jcliff.Configurable.resolve1(Configurable.java:288)
at com.redhat.jcliff.Configurable.func(Configurable.java:432)
at com.redhat.jcliff.Configurable.resolve(Configurable.java:329)
at com.redhat.jcliff.Configurable.getScript(Configurable.java:261)
at com.redhat.jcliff.Main.execute(Main.java:378)
at com.redhat.jcliff.Main.executeRules(Main.java:337)
at com.redhat.jcliff.Main.main(Main.java:242)
Below is the jcliff file used:
{
"ee" => {
"global-modules" =>
[{
"name" => "com.ingenico.properties",
"slot" => "main"
}
],
"annotation-property-replacement" => false,
"ear-subdeployments-isolated" => false,
"jboss-descriptor-property-replacement" => true,
"spec-descriptor-property-replacement" => false
}
}
The manual configuration with jboss-cli is OK:
/subsystem=ee:write-attribute(name=global-modules,value=[{name=> "com.ingenico.properties", slot => "main"}])
Note that with jcliff 2.9.14 the rule was OK
Can you check what is wrong ?
Thank you
When running a JCLiff script like this every modification will be a jboss-cli.sh command (meaning every command will spin up a JVM). You'll have ~ 30 jvms starting up and change in a non batch manner the standalone.xml file : check the history in configuration/standalone_xml_history
Performance-wise this is not very efficient.
Idea :
{
"datasource" => {
"TestDS" => {
"jndi-name" => "java:jboss/datasources/Test",
"connection-url" => "jdbc:postgresql://localhost:5432/test",
"driver-name" => "h2",
"user-name" => "test",
"password" => "test",
"enabled" => "true",
"new-connection-sql" => "select 1",
"min-pool-size" => "1",
"max-pool-size" => "50",
"pool-prefill" => "true",
"prepared-statements-cache-size" => "20",
"idle-timeout-minutes" => "1",
"allocation-retry" => undefined,
"allocation-retry-wait-millis" => undefined,
"allow-multiple-users" => false,
"background-validation" => undefined,
"background-validation-millis" => undefined,
"blocking-timeout-wait-millis" => undefined,
"check-valid-connection-sql" => undefined,
"connectable" => false,
"datasource-class" => undefined,
"driver-class" => undefined,
"exception-sorter-class-name" => undefined,
"exception-sorter-properties" => undefined,
"flush-strategy" => undefined,
"jta" => true,
"pool-use-strict-min" => undefined,
"query-timeout" => undefined,
"reauth-plugin-class-name" => undefined,
"reauth-plugin-properties" => undefined,
"security-domain" => undefined,
"set-tx-query-timeout" => false,
"share-prepared-statements" => false,
"spy" => false,
"stale-connection-checker-class-name" => undefined,
"stale-connection-checker-properties" => undefined,
"statistics-enabled" => false,
"track-statements" => "NOWARN",
"transaction-isolation" => undefined,
"url-delimiter" => undefined,
"url-selector-strategy-class-name" => undefined,
"use-ccm" => true,
"use-fast-fail" => false,
"use-java-context" => true,
"use-try-lock" => undefined,
"valid-connection-checker-class-name" => undefined,
"valid-connection-checker-properties" => undefined,
"validate-on-match" => false,
}
}
}
When executing JCliff like this with directory ${RPM_APP_JBOSSCLI_CONF_DIR} being empty, JCliff should return 0 instead of an error. Check if directory exists, check if files exist.
${JCLIFF_HOME}/jcliff --cli=${JBOSS_HOME}/bin/jboss-cli.sh -v --controller=${JBOSS_MANAGEMENT_HOST}:${JBOSS_MANAGEMENT_PORT} --output=${JCLIFF_LOG_DIR}/jcliff.log ${RPM_APP_JBOSSCLI_CONF_DIR}/*.cliff
.
I defined a new security-domain containing 2 login modules. This had issues when I defined them with "login-modules" instead of "login-module" node/element. Here's the git diff of first attempt at config file:
+{
"InstructorCentralSecurityDomain" => {
"authentication" => {
"classic" => {
"login-modules" => {
"com.redhat.container.TicketServiceLoginModule" => {
"code"=>"com.redhat.container.TicketServiceLoginModule",
"flag"=>"required",
"module-options"=>{
"password-stacking"=>"useFirstPass",
}
},
"com.redhat.instructorcentral.web.security.ICPermissionsLoginModule" => {
"code"=>"com.redhat.instructorcentral.web.security.ICPermissionsLoginModule",
"flag"=>"required",
"module-options"=>{
"password-stacking"=>"useFirstPass",
}
}
}
}
}
}
Then I changed it as here:
"authentication" => {
"classic" => {
"login-modules" => {
"login-module" => {
"com.redhat.container.TicketServiceLoginModule" => {
"code"=>"com.redhat.container.TicketServiceLoginModule",
Finally, I modified the name of one of the login modules, and this resulted in a 3rd login-module being defined for my security-domain. One of the three login-module definitions now also included a 'name' attribute that matched the 'code' attribute value. The modification is as here:
"login-module" => {
"com.redhat.container.TicketServiceLoginModule" => {
"code"=>"com.redhat.container.TicketServiceLoginModule",
"com.redhat.instructorcentral.web.security.ICTicketServiceLoginModule" => {
"code"=>"com.redhat.instructorcentral.web.security.ICTicketServiceLoginModule",
"flag"=>"required",
"module-options"=>{
At one point, I recall trying to add the "module-options" to an existing login-module that did not define a module-options. I would have done that manually by editing the config file in /etc/redhat/eap6 and then running puppet manually against that config file. In that case, it also caused a 'name' attribute to be added to the login-module and the value matched the value of the 'code' attribute.
As of today it is not possible to add global modules via JCliff.
Global modules are underneath the ee subsystem.
Create a new rule rules/ee would be needed to do so.
to start easily with jcliff you need to add a shell function that lets you :
convert_jboss-cli_to_json.sh "localhost:9999" "/subsystem=infinispan/cache-container=web:read-resource(recursive=true)"
which returns the JSON block that can be read by JCliff !
/subsystem=infinispan/cache-container=web:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"aliases" => ["standard-session-cache"],
"default-cache" => "local-web",
"eviction-executor" => undefined,
"jndi-name" => undefined,
"listener-executor" => undefined,
"module" => "org.jboss.as.clustering.web.infinispan",
"replication-queue-executor" => undefined,
"start" => undefined,
"statistics-enabled" => undefined,
"distributed-cache" => undefined,
"invalidation-cache" => undefined,
"local-cache" => {"local-web" => {
"batching" => true,
"indexing" => undefined,
"indexing-properties" => undefined,
"jndi-name" => undefined,
"module" => undefined,
"start" => undefined,
"statistics-enabled" => undefined,
"binary-keyed-jdbc-store" => undefined,
"eviction" => undefined,
"expiration" => undefined,
"file-store" => {"FILE_STORE" => {
"fetch-state" => true,
"passivation" => false,
"path" => undefined,
"preload" => false,
"purge" => false,
"relative-to" => "jboss.server.data.dir",
"shared" => false,
"singleton" => false,
"property" => undefined,
"write-behind" => undefined
}},
"locking" => undefined,
"mixed-keyed-jdbc-store" => undefined,
"remote-store" => undefined,
"store" => undefined,
"string-keyed-jdbc-store" => undefined,
"transaction" => undefined
}},
"replicated-cache" => undefined,
"transport" => undefined
},
"response-headers" => {"process-state" => "reload-required"}
}
{
"infinispan" => {
"cache-container" => {
"web" => {
"aliases" => ["standard-session-cache"],
"default-cache" => "local-web",
"eviction-executor" => undefined,
"jndi-name" => undefined,
"listener-executor" => undefined,
"module" => "org.jboss.as.clustering.web.infinispan",
"replication-queue-executor" => undefined,
"start" => undefined,
"statistics-enabled" => undefined,
"distributed-cache" => undefined,
"invalidation-cache" => undefined,
"local-cache" => {"local-web" => {
"batching" => true,
"indexing" => undefined,
"indexing-properties" => undefined,
"jndi-name" => undefined,
"module" => undefined,
"start" => undefined,
"statistics-enabled" => undefined,
"binary-keyed-jdbc-store" => undefined,
"eviction" => undefined,
"expiration" => undefined,
"file-store" => {"FILE_STORE" => {
"fetch-state" => true,
"passivation" => false,
"path" => undefined,
"preload" => false,
"purge" => false,
"relative-to" => "jboss.server.data.dir",
"shared" => false,
"singleton" => false,
"property" => undefined,
"write-behind" => undefined
}},
"locking" => undefined,
"mixed-keyed-jdbc-store" => undefined,
"remote-store" => undefined,
"store" => undefined,
"string-keyed-jdbc-store" => undefined,
"transaction" => undefined
}},
"replicated-cache" => undefined,
"transport" => undefined
}
}
}
}
Impact is jboss gets into a broken state. Can we have jcliff exit with an error after a timeout? Then at least there's an opportunity to see things are broken.
The timeout introduced in the fix for #38 can cause issues. I think at the very least, this timeout should be configurable.
If you try to deploy a bunch of artifacts in a single Jcliff run, then it can easily take longer than 20 seconds.
Additionally, the sudden killing of the jboss-cli can leave JBoss in a weird state.
It is not possible to add a 'security-realm' under 'management'.
I am using the following commands in jboss-cli.sh console:
/core-service=management/security-realm=MyRealm:add
/core-service=management/security-realm=MyRealm/authentication=jaas:add(name="my-proxy")
Can you please add a rule to add and modify a security-realm ?
Since a lot is taking place behind the scenes which may not be visible in the output even when -v is specified, it could be very helpful to still have the *.tmp files generated by JCliff to ease debugging and trace-back a change. Would it be possible to either
{
"path" => {
"jboss.server.app-config.dir" => {
"name" => "jboss.server.appconfig.dir",
"path" => "/app-configuration",
"relative-to" => "jboss.server.data.dir"
}
}
}
After having executed this once, it does not check running a second time if it already exists ! Tries to write attribute --> fails --> ERROR.
I should either not output an error, as the values have not changed during the second run.
It should delete it first and recreate it behind.
We need something like ${if-defined , , } in rules, so we can process optional fields, like "module-slot" in jdbc-driver
NodePath.getPaths() adds node.toString to the path. There should be a better way of doing this.
Please make the following configurable (in infinispan/cache-container):
Example:
<cache-container name="bla" default-cache="blaCache" jndi-name="java:jboss/infinispan/container/bla" start="EAGER" module="com.foo.bla.cache">
<transport stack="tcp" cluster="bla-cache-cluster" lock-timeout="60000"/>
<replicated-cache name="blaCache" batching="true" mode="SYNC">
<locking isolation="REPEATABLE_READ"/>
<eviction strategy="NONE" max-entries="1000"/>
<expiration max-idle="600000" lifespan="288000000" interval="500"/>
</replicated-cache>
[...]
</cache-container>
Thanks.
This is just a nice-to-have, but could come in handy sometimes. Makes it easier to understand what cliff is currently doing.
If running jcliff from puppet each line of text in the stack trace is added to the puppet output, which in slow puppet environments is excruciatingly slow.
Hi
I've upgraded jcliff from 2.10.8 to 2.11.3 and the xadatasource rules file has changed. The precedence for adding xa-datasource-properties has changed
From addXAProperty.precedence=70
To addXAProperty.precedence=10
This causes a failure to add an xa-datasource since jcliff tries to add the properties first before creating the datasource.
The error in the log is
2016-08-02 13:45:20:0731: Return:{
"outcome" => "failed",
"failure-description" => "JBAS014766: Resource [
("subsystem" => "datasources"),
("xa-data-source" => "ds_xatest2")
] does not exist; a resource at address [
("subsystem" => "datasources"),
("xa-data-source" => "ds_xatest2"),
("xa-datasource-properties" => "DatabaseName")
] cannot be created until all ancestor resources have been added",
"rolled-back" => true
}
Replacing the rule file with the one from v2.10.8 allows the config to proceed.
This is the current config file
{ "xadatasource" => {
"ds_xatest2" => {
"enabled" => "true",
"jndi-name" => "java:/jboss/datasources/test1",
"pool-name" => "java:/jboss/datasources/test2",
"driver-name" => "postgresql-jdbc42",
"security-domain" => "MytestDS",
"xa-datasource-properties" => {
"DatabaseName" => { "value" => "mydb" },
"ServerName" => { "value" => "myserver" },
}
}
}
}
Thanks
Shaun
xadatasource resource requires you to set the URL, but not all xa datasources support this property, such as postgresql. All xa-datasource-properties should be optional.
https://github.com/bserdar/jcliff/blob/master/src/main/resources/xadatasource
--xa-datasource-properties=[{URL=${value(xa-datasource-properties/URL/value)}}]
Hi
After adding ssl on the security-realm it requires a reload. Can this please be added.
/core-service=management/security-realm=CertificateRealm/server-identity=ssl:add(..)
Or is there another way I can initiate a reload? I would prefer not doing using the command line option --reload.
If being called with --reload, jcliff should say whether it reloaded JBoss/WildFly or not.
Error checking is broken, causing infinite loops.
"unbounded-queue-thread-pool" => {"uq-thread-pool" => {
"keepalive-time" => {
"time" => 30L,
"unit" => "SECONDS"
},
"max-threads" => 100,
"name" => "uq-thread-pool",
"thread-factory" => "http-connector-factory"
}}
}
No rules for diffs:undefine:/threads/blocking-bounded-queue-thread-pool value=undefined
undefine:/threads/blocking-queueless-thread-pool value=undefined
undefine:/threads/bounded-queue-thread-pool value=undefined
undefine:/threads/queueless-thread-pool value=undefined
undefine:/threads/scheduled-thread-pool value=undefined
Exception in thread "main" java.lang.RuntimeException: Operation failed:{"outcome" => "failed","failure-description" => "JBAS014688: Wrong type for time. Expected [EXPRESSION, LONG] but was STRING","rolled-back" => true,"response-headers" => {"process-state" => "reload-required"}}
at com.redhat.jcliff.Configurable$DefaultPostprocessor.process(Configurable.java:59)
at com.redhat.jcliff.Ctx.runcmd(Ctx.java:70)
at com.redhat.jcliff.Ctx.runQueuedCmds(Ctx.java:99)
Hi,
I'm trying to get rid of these messages:
No rules for diffs:modify:/jdbc-driver/oracle-driver/driver-module-name value="com.oracle.ojdbc6"(/jdbc-driver/oracle-driver/driver-module-name value="com.oracle.ojdbc6:main")
modify:/jdbc-driver/oracle-driver/driver-datasource-class-name value="oracle.jdbc.OracleDatasource"(/jdbc-driver/oracle-driver/driver-datasource-class-name value=undefined)
modify:/jdbc-driver/oracle-driver/xa-datasource-class value="oracle.jdbc.xa.client.OracleXADataSource"(/jdbc-driver/oracle-driver/xa-datasource-class value=undefined)
modify:/jdbc-driver/oracle-driver/module-slot value="main"(/jdbc-driver/oracle-driver/module-slot value=undefined)
The file creating the datasource looks like this:
{
"jdbc-driver" => {
"oracle-driver" =>
{
"driver-name" => "oracle-driver",
"driver-module-name" => "com.oracle.ojdbc6",
"driver-datasource-class-name" => "oracle.jdbc.OracleDatasource",
"driver-xa-datasource-class-name" => "oracle.jdbc.xa.client.OracleXADataSource",
"xa-datasource-class" => "oracle.jdbc.xa.client.OracleXADataSource",
"driver-class-name" => "oracle.jdbc.driver.OracleDriver",
"module-slot" => "main",
}
}
}
I've tried adding a rule to jdbc-driver allowing the attributes to be modified, but it doesn't behave as expected, because the attributes are readonly.
Furthermore it seems that driver-module-name
needs to be used differently than when creating the driver (com.oracle.ojdbc6
vs. com.oracle.ojdbc6:main
),
so treating it like system-properties would just cause endless restarts again, right?
jcliff 2.10.4 adds connection properties support for datasources, thanks for that. However, I can use jcliff only to modify existing connection-properties. Adding new ones doesn't work. It seems that both addConnProperties
and modifyConnProperties2
rules are triggered:
"connection-properties" =>
{
"cacheServerConfiguration" => { "value" => "true" },
},
results in
2015-08-05 10:20:00:0751: modifyConnProperties2 will be run on add:/datasource/SomeReadDS/connection-properties/cacheServerConfiguration/value value="true"
2015-08-05 10:20:00:0752: run:/subsystem=datasources/data-source= SomeReadDS/connection-properties=cacheServerConfiguration:remove
/subsystem=datasources/data-source= SomeReadDS/connection-properties=cacheServerConfiguration:add(value="true")
2015-08-05 10:20:00:0752: Checking rule delete
2015-08-05 10:20:00:0752: Checking rule addConnProperties
2015-08-05 10:20:00:0752: addConnProperties will be run on add:/datasource/SomeReadDS/connection-properties/cacheServerConfiguration value={"value" => "true"}
2015-08-05 10:20:00:0753: run:/subsystem=datasources/data-source= SomeReadDS/connection-properties=cacheServerConfiguration:add(value="true")
2015-08-05 10:20:00:0753: Checking rule modify
2015-08-05 10:20:00:0753: Checking rule add
2015-08-05 10:20:00:0753: Checking rule modifyConnProperties
2015-08-05 10:20:00:0753: Checking rule removeConnProperties
Please add support for the following properties of a datasource:
this will work :
{ "jdbc-driver" =>
{ "PostgresDriver" => {
"driver-name" => "PostgresDriver",
"driver-module-name" => "org.postgresql",
"driver-xa-datasource-class-name" => "org.postgresql.xa.PGXADataSource"
}
}
}
this won't work :
{ "jdbc-driver" =>
{ "PostgresDriver" => {
"driver-name" => "PostgresDriver",
"driver-module-name" => "org.postgresql",
"driver-datasource-class-name" => "org.postgresql.ds.PGSimpleDataSource"
}
}
}
please double check that you can set "driver-class-name" also....
When trying to apply both *.json files at the same time, JCliff will stop with the following error :
Exception in thread "main" java.lang.RuntimeException: Operation failed:{"outcome" => "failed","failure-description" => "JBAS014762: Removing services has lead to unsatisfied dependencies:
Service jboss.jdbc-driver.h2 was depended upon by service jboss.data-source.java:jboss/datasources/ExampleDS, service jboss.driver-demander.java:jboss/datasources/ExampleDS","rolled-back" => true}
at com.redhat.jcliff.Configurable$DefaultPostprocessor.process(Configurable.java:59)
at com.redhat.jcliff.Ctx.runcmd(Ctx.java:70)
at com.redhat.jcliff.Ctx.runQueuedCmds(Ctx.java:99)
at com.redhat.jcliff.Main.main(Main.java:230)
1_datasource-remove-exampleds.json
{
"datasource" => {
"ExampleDS" => "deleted"
}
}
2_driver-remove-h2.json
{ "jdbc-driver" =>
{ "h2" => "deleted"
}
}
Hi,
I'd need to have support for authentication-jaspi like so:
<security-domain name="abc" cache-type="default">
<authentication-jaspi>
<login-module-stack name="lm-stack">
<login-module code="Dummy" flag="required"/>
</login-module-stack>
<auth-module code="com.foo.bar.SomeModule" flag="required" login-module-stack-ref="lm-stack">
<module-option name="foo" value="bar"/>
</auth-module>
</authentication-jaspi>
</security-domain>
Thanks a lot
--Markus
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.