<div dir="ltr">I have a PR that builds on Brian's work for the web migrate op: <a href="https://github.com/wildfly/wildfly/pull/7931">https://github.com/wildfly/wildfly/pull/7931</a><div><br></div><div>Output is:</div><div><br></div><div>Standard EAP config (no warnings or errors):</div><div><br></div><div><div>[standalone@localhost:9999 /] /subsystem=web:migrate</div><div>{</div><div> "outcome" => "success",</div><div> "result" => {"migration-warnings" => []}</div><div>}</div></div><div><br></div><div>Success with a warning (in this case due to an invalid protocol attribute on a connector):</div><div><br></div><div><div>[standalone@localhost:9999 /] /subsystem=web:migrate</div><div>{</div><div> "outcome" => "success",</div><div> "result" => {"migration-warnings" => ["WFLYWEB0002: Could not migrate resource {</div><div> \"protocol\" => \"INVALID\",</div><div> \"scheme\" => \"http\",</div><div> \"socket-binding\" => \"ajp\",</div><div> \"enable-lookups\" => undefined,</div><div> \"proxy-binding\" => undefined,</div><div> \"proxy-name\" => undefined,</div><div> \"proxy-port\" => undefined,</div><div> \"redirect-binding\" => undefined,</div><div> \"redirect-port\" => undefined,</div><div> \"secure\" => undefined,</div><div> \"max-post-size\" => undefined,</div><div> \"max-save-post-size\" => undefined,</div><div> \"enabled\" => undefined,</div><div> \"executor\" => undefined,</div><div> \"max-connections\" => undefined,</div><div> \"virtual-server\" => undefined,</div><div> \"name\" => \"ajp\",</div><div> \"operation\" => \"add\",</div><div> \"address\" => [</div><div> (\"subsystem\" => \"web\"),</div><div> (\"connector\" => \"ajp\")</div><div> ]</div><div>}"]}</div><div>}</div></div><div><br></div><div>Failed OP:</div><div><div><br></div><div>[standalone@localhost:9999 /] /subsystem=web:migrate</div><div>{</div><div> "outcome" => "failed",</div><div> "result" => {</div><div> "migration-warnings" => [],</div><div> "migration-error" => {</div><div> "operation" => {</div><div> "operation" => "add",</div><div> "address" => [</div><div> ("subsystem" => "undertow"),</div><div> ("server" => "default-server"),</div><div> ("ajp-listener" => "ajp")</div><div> ],</div><div> "socket-binding" => "ajp",</div><div> "secure" => undefined,</div><div> "redirect-socket" => undefined,</div><div> "enabled" => undefined,</div><div> "resolve-peer-address" => undefined,</div><div> "max-post-size" => undefined,</div><div> "max-connections" => "sadfadsfasdgasdfg",</div><div> "operation-headers" => {</div><div> "caller-type" => "user",</div><div> "access-mechanism" => "NATIVE"</div><div> },</div><div> "worker" => undefined,</div><div> "buffer-pool" => undefined,</div><div> "disallowed-methods" => undefined,</div><div> "max-header-size" => undefined,</div><div> "buffer-pipelined-data" => undefined,</div><div> "max-parameters" => undefined,</div><div> "max-headers" => undefined,</div><div> "max-cookies" => undefined,</div><div> "allow-encoded-slash" => undefined,</div><div> "decode-url" => undefined,</div><div> "url-charset" => undefined,</div><div> "always-set-keep-alive" => undefined,</div><div> "max-buffered-request-size" => undefined,</div><div> "record-request-start-time" => undefined,</div><div> "allow-equals-in-cookie-value" => undefined,</div><div> "no-request-timeout" => undefined,</div><div> "request-parse-timeout" => undefined,</div><div> "tcp-backlog" => undefined,</div><div> "receive-buffer" => undefined,</div><div> "send-buffer" => undefined,</div><div> "tcp-keep-alive" => undefined,</div><div> "read-timeout" => undefined,</div><div> "write-timeout" => undefined</div><div> },</div><div> "result" => {</div><div> "outcome" => "failed",</div><div> "failure-description" => "WFLYCTL0097: Wrong type for max-connections. Expected [INT] but was STRING",</div><div> "rolled-back" => true</div><div> }</div><div> }</div><div> },</div><div> "rolled-back" => true</div><div>}</div></div><div><br></div><div>Stuart</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 14 Aug 2015 at 11:03 Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/13/15 10:03 AM, Brian Stansberry wrote:<br>
> On 8/13/15 3:11 AM, Stuart Douglas wrote:<br>
>><br>
>><br>
>> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon <<a href="mailto:lthon@redhat.com" target="_blank">lthon@redhat.com</a><br>
>> <mailto:<a href="mailto:lthon@redhat.com" target="_blank">lthon@redhat.com</a>>> wrote:<br>
>><br>
>><br>
>> > The approach I took was to add the warnings to the describe-migration<br>
>> > op, and when running the migrate op make the describe-migration<br>
>> > operation the first step in the composite, so the output looks like<br>
>> > this: <a href="http://pastebin.com/B01KNAHX" rel="noreferrer" target="_blank">http://pastebin.com/B01KNAHX</a><br>
>><br>
>> The fact that it's a composite operation makes the output a bit cryptic<br>
>> (step-X?), but otherwise I think it's actually good.<br>
>><br>
>> I guess that only handling the warnings in :describe-migration makes the<br>
>> implementation easier (not sure?) and printing :describe-migration as a<br>
>> part of :migrate makes sense too, precisely because it shows the steps<br>
>> that are performed.<br>
>><br>
>> So my only objection would be those cryptic "step-X" names, but I guess<br>
>> that we can live with that (if all :migrate operations took the same<br>
>> approach; inconsistency wouldn't really help here).<br>
>><br>
>><br>
>> That is because this is implemented as a composite operation, AFAIK<br>
>> there is lots of special handing for composite ops, so I don't think we<br>
>> want to be implementing our own one with different output just for this<br>
>> case.<br>
>><br>
>> I could be wrong though, this is not really my area, Brian will know more.<br>
>><br>
><br>
> In the success case, I don't see the point of outputting "step-2" =><br>
> {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc.<br>
><br>
> In the failure case though, having an intelligible failure-description<br>
> is important. And the composite op handler may be getting in your way there<br>
><br>
> Instead of writing more text, I'll write some code to illustrate some<br>
> thoughts and post back later.<br>
><br>
<br>
Here's what I was thinking.<br>
<br>
[1] is a change to break out the step registration stuff<br>
CompositeOperationHandler does into a utility method, with a couple<br>
other variants added that are better suited for use by other OSHs.<br>
<br>
Basically, it lets you pass in a Map of ops and a holder map of response<br>
nodes, and it will add the steps and populate the response node map.<br>
(You can optionally pre-populate the response node map. There's also a<br>
variant that uses lists instead of maps in case that's more convenient.)<br>
<br>
Using that, the response nodes for the added ops don't have to directly<br>
appear in the overall operation response. Instead the migrate op handler<br>
can hold a ref to them and in its ResultHandler use them to format an<br>
understandable response.<br>
<br>
The top two commits in [2] are an example tweak to the current<br>
WebMigrationOp in master to illustrate use of this.<br>
<br>
[1] <a href="https://github.com/wildfly/wildfly-core/pull/956" rel="noreferrer" target="_blank">https://github.com/wildfly/wildfly-core/pull/956</a><br>
<br>
[2] <a href="https://github.com/bstansberry/wildfly/tree/help-migrate-multistep" rel="noreferrer" target="_blank">https://github.com/bstansberry/wildfly/tree/help-migrate-multistep</a><br>
<br>
>> Stuart<br>
>><br>
>><br>
>> LT<br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>><br>
><br>
><br>
<br>
<br>
--<br>
Brian Stansberry<br>
Senior Principal Software Engineer<br>
JBoss by Red Hat<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>