[
https://issues.jboss.org/browse/WFLY-5306?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-5306:
----------------------------------------
I believe the technical issue I meant was that removing the extension within the series of
execution steps may interfere with the execution of the other steps, since the removal
will mean all the resource definitions and handlers associated with the legacy extension
will be gone.
This is probably an avoidable issue, avoided via careful arrangement of step execution.
Perhaps trivially avoided just by doing things in the intuitively obvious order.
Should the :migrate operation remove the legacy extension in
standalone?
------------------------------------------------------------------------
Key: WFLY-5306
URL:
https://issues.jboss.org/browse/WFLY-5306
Project: WildFly
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 10.0.0.Beta2
Reporter: Ladislav Thon
Assignee: Stuart Douglas
Priority: Critical
The {{:migrate}} management operation creates a new subsystem and removes the legacy
subsystem. It also adds an extension for the new subsystem, but it doesn't remove the
legacy extension.
The legacy extension must of course stay in place in managed domain (the {{:migrate}}
operation could be clever and check other profiles if they still have the subsystem, but
I'd consider this behavior out of scope), but for standalone, I think the extension
could and should be removed. Ideas?
Brian noted \[1\] that there might be technical obstacles in removing the extension, in
which case I of course agree with rejecting.
\[1\]
http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004287.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)