bserdar / jcliff Goto Github PK

View Code? Open in Web Editor NEW

43.0 13.0 26.0 83.66 MB

Manage JBossAS 7/EAP6/Wildfly with modular configuration files from command line, puppet, ansible, chef, etc.

License: Other

Shell 3.66% Puppet 4.35% HTML 5.85% Java 85.27% Batchfile 0.88%

jboss puppet ansible configuration-management wildfly jboss-eap

jcliff's People

Contributors

Stargazers

Watchers

jcliff's Issues

Bad performance when running detailed JSON scripts (on creation)

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 :

use a custom connector to JBoss that uses one single JVM and that passes in commands
use batch commands within cli

{
"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,
}
}
}

jboss changes from "running" to "reload-required" on every puppet run due to one parameter

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",
}
}
}

RFE : Executing JCliff on an empty directory should return 0 instead of 1 (error)

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

Jcliff treats 30L as string, not as long

   "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)

at com.redhat.jcliff.Main.main(Main.java:209)

No rules for diffs:add:/subsystem/undertow/server/default-server/http-listener

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"

What file to pass as an argument?

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)

xa datasource requires you to set xa-datasource-properties for URL

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)}}]

Update puppet code, bring more stuff from the production version into here.

No rules for diffs:add:/configuration/filter/gzip/name value="gzipFilter"

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?

JDBC driver properties can't be modified

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?

Write a document that describes what's supported

...or, write a script that'll generate that from the rules.

Processing changed login-module(s) has issues

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:

"security" => {
"security-domain" => {

 "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.

it would be good to have a tool to create the initial json file for jcliff configs

no script available that converts jboss-cli output to json block

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 !

Example :

this is the starting point

/subsystem=infinispan/cache-container=web:read-resource(recursive=true)

the whole JSON part of the jboss-cli (the return value has to be taken out)

{
"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"}
}

adding 3 json hierarchies in front of result : infinispan cache-container web

the expected result !!!

{
"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





       }
   }

}
}

Add slot capability to a new driver

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

Need to add conditional processing

We need something like ${if-defined , , } in rules, so we can process optional fields, like "module-slot" in jdbc-driver

Add support for undeploy

There is no way to undeploy an app.

Jcliff timeout can cause issues

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.

XA Datasources not working with Wildfly 8.2.0.Final

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(.)}

Print executed CLI commands in verbose mode

This is just a nice-to-have, but could come in handy sometimes. Makes it easier to understand what cliff is currently doing.

rewrite object in web subsystem rule in not processed

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
        }}
    }
}

Add a rule to modify remoting connector attributes

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 ?

Add support for datasource properties

Please add support for the following properties of a datasource:

validation
- check-valid-connection-sql
- validate-on-match
- background-validation
- background-validation-millis
- ...
timeout
- set-tx-query-timeout
- blocking-timeout-millis
- idle-timeout-minutes
- query-timeout
- use-try-lock
- allocation-retry
- allocation-retry-wait-millis
- ...

using value deleted does not work in all cases

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:{}

jcliff should say whether it reloaded JBoss/WildFly or not

If being called with --reload, jcliff should say whether it reloaded JBoss/WildFly or not.

ee rule execution raised exception

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

JBoss CLI offline mode support

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#

Fix error checking

Error checking is broken, causing infinite loops.

jcliff hangs if jboss-cli hangs

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.

Make replicated-cache more configurable

Please make the following configurable (in infinispan/cache-container):

replicated-cache
- expiration
  - max-idle
  - life-span
  - interval

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.

No rules for diffs:modify for jdbc-driver submodule

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 %>"
    }
  }
}

jcliff sometimes doesn't wait for WildFly long enough

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)?

adding extra path is not working

{
"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.

Please make NOOPs silent

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.

Optionally do not remove generated *.tmp files to ease debugging and trace-back

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

introduce a new command line option to request this (e. g. -d for debug or -k for keep)?
just leave the .tmp files there when -v is specified?
Thanks, and best regards,
Heinz

Support for authentication-jaspi

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

Specify the driver class (non XA) when creating a driver is not possible

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....

wildfly doesn't reload although necessary

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.

list processing is broken

NodePath.getPaths() adds node.toString to the path. There should be a better way of doing this.

JCliff in a JBoss (EAP6) Domain Environment

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

Removing driver (h2) & datasource (ExampleDS) won't work at the same time

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"
}
}

reload after adding ssl

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.

Don't output full stack trace if cannot connect to jboss

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.

Pair undeployments with deployments, so a failed deployment won't undeploy unaffacted apps

Add security-realm rule

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 ?

Managing Mail resources

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)

RFE : add ee subsystem to the JCliff rules

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.

Adding new connection properties support to datasources doesn't work

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

xadatasource precedence incorrect?

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

user/group jboss does not exist

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.