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

[Ladislav Thon (JIRA)]

     [ https://issues.jboss.org/browse/WFCORE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.



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



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)