Inline.
> I believe that the :migrate operations _could_ return these
warnings in
> the operation result, but since Brian thinks that this is problematic,
> I'll have to leave the details up to you, guys :-)
>
It can be done, and IMHO must be done if the handler is ignoring aspects
of the migrated configuration.
100% agreed.
It just means altering the format of the
result of both the "migrate" and "describe-migration" operations.
The "warnings" can only be for items identified by the migration op
handler directly. If any of the various add/remove ops that that handler
tells the controller to execute fail, then the overall result will be a
failure. That is, no attempt to hack into the handling of those ops and
convert that kind of failure into a "warn".
I think this is expected and I'm fine with it.
I propose the following format for the "result" field of
the migrate
operation response:
{
"migration-warnings"=>[
"WFXXX1234: the blah is blah",
"WFXXX2345: the foo is barred"
]
}
The "result" field currently contains a name and version of newly
created subsystem, which should probably be preserved:
[standalone@localhost:9990 /] /subsystem=jacorb:migrate
{
"outcome" => "success",
"result" => [("iiop-openjdk" => "1.0.0")]
}
For "describe-migration":
{
"migration-warnings"=>[
"WFXXX1234: the blah is blah",
"WFXXX2345: the foo is barred"
],
"migration-operations=>[
{ an operation },
{ another operation}
]
}
The value of the "migration-operations" field would be the same as the
overall result value currently produced by these ops.
Sounds good.
LT