[wildfly-dev] Migration management operation - open questions

[Stuart Douglas]

I don't think it should fail, imagine how frustrating that would be from a
users perspective, as the only course of action they have is to delete the
relevant resource and try again. It would be much more user friendly IMHO
to just let the op complete and then they can fix up any issues, they will
still end up in the same situation, just with less work on their part.

Stuart



On Tue, 11 Aug 2015 at 10:40 Jason Greene <jason.greene at redhat.com> wrote:

>
> On Aug 10, 2015, at 5:23 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
>
>> > 3. What is the expected behavior when part which was configured as part
>> of the legacy subsystem is now configured outside of new subsystem having
>> just reference to it? Should the migration operation create the additional
>> configuration even when it is manipulating with configuration parts outside
>> of the subsystem?
>> > -- For example ssl configuration of https connector/listener. In Web
>> subsystem it is part of the connector configuration, in Undertow it is just
>> reference to security realm and it is defined as part of the security
>> realms, should new security realm be created with equivalent configuration
>> to the one in legacy Web subsystem?
>> >
>>
>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the
>> handler for the web subsystem migrate op) it looks to be adding a
>> security realm.
>>
>
> Yes, at the moment I do create new security realms, and also add the IO
> subsystem with a default config if it is not already present. The names for
> the security realm will be jbossweb-migration-security-realm(n), where n is
> the lowest number that does not result in a name collision.
>
>
> As an example of the fail-or-warn question, unless I am reading the code
> wrong, it looks like things which don’t have a mapping (e.g. tomcat valves)
> are ignored. Should the migration op fail if one is used, or should it
> return a warning?
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150811/2ff0b4aa/attachment-0001.html