[jboss-jira] [JBoss JIRA] (WFCORE-526) "patch apply" over a CommandContext bound to existing ModelControllerClient fails

Ladislav Thon (JIRA) issues at jboss.org
Fri Jan 30 07:18:49 EST 2015


Ladislav Thon created WFCORE-526:
------------------------------------

             Summary: "patch apply" over a CommandContext bound to existing ModelControllerClient fails
                 Key: WFCORE-526
                 URL: https://issues.jboss.org/browse/WFCORE-526
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI, Patching 
            Reporter: Ladislav Thon
            Assignee: Alexey Loubyansky


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)


More information about the jboss-jira mailing list