Details
-
Bug
-
Resolution: Done
-
Major
-
None
-
None
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:
ModelControllerClient client = ...; CommandContext cliContext = CommandContextFactory.getInstance().newCommandContext(); cliContext.bindClient(client);
Then, I try to invoke the patch apply operation like this:
cliContext.handle("patch apply path/to/patch.zip");
This results in an exception:
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
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).
