[ https://issues.jboss.org/browse/WFCORE-526?page=com.atlassian.jira.plugin... ] Ladislav Thon updated WFCORE-526: --------------------------------- Description: I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client: {code} ModelControllerClient client = ...; CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext(); cliContext.bindClient(client); {code} Then, I try to invoke the {{patch apply}} operation like this: {code} cliContext.handle("patch apply path/to/patch.zip"); {code} This results in an exception: {code} Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip' at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660) at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545) at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518) at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275) at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651) ... 6 more {code} The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}. IMHO, patching code should use a more intelligent method to find out if it is connected to a running server. Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used. For reproducing, the "client" application depends on {{org.wildfly.core:wildfly-controller-client:1.0.0.Alpha16}} and {{org.wildfly.core:wildfly-patching:1.0.0.Alpha16}}, while the server is a clean build from current WildFly master (commit {{2ea95a18}}). was: I'm trying to apply a patch programmatically, using CLI as the API (which might be a bad idea, but all I'm doing is using public methods and interfaces). I already have a {{ModelControllerClient}}, so I create a {{CommandContext}} and bind it to my client: {code} ModelControllerClient client = ...; CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext(); cliContext.bindClient(client); {code} Then, I try to invoke the {{patch apply}} operation like this: {code} cliContext.handle("patch apply path/to/patch.zip"); {code} This results in an exception: {code} Exception in thread "main" org.jboss.as.cli.CommandLineException: Failed to handle 'patch apply /home/lthon/Downloads/jboss-eap-6.3.3.CP.CR2-patch.zip' at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:660) at cz.ladicek.wildfly.PatchingErrorReproducer.main(PatchingErrorReproducer.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) Caused by: java.lang.IllegalStateException: failed to resolve a jboss.home.dir use the --distribution attribute to point to a valid installation at org.jboss.as.patching.cli.PatchHandler.getJBossHome(PatchHandler.java:545) at org.jboss.as.patching.cli.PatchHandler.createPatchOperationTarget(PatchHandler.java:518) at org.jboss.as.patching.cli.PatchHandler.doHandle(PatchHandler.java:275) at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88) at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:651) ... 6 more {code} The reason is that the patching CLI code, specifically the {{PatchHandler.createPatchOperationTarget}} method, reads {{CommandContext.getControllerHost()}} to find out if it is connected to a running server. In my case, {{getControllerHost()}} returns {{null}} because it was initialized using already-existing {{ModelControllerClient}}. IMHO, patching code should use a more intelligent method to find out if it is connected to a running server. Alternatively, this could be formulated as a bug of the core CLI code, because the {{getControllerHost()}} method is documented to _return the host the controller client is connected to or null if the connection hasn't been established yet_, which is arguably a lie when {{CommandContext.bindClient}} is used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)