[wildfly-dev] Easing migration beyond the migration ops

[Brian Stansberry]

On 8/12/15 4:54 AM, Tomaž Cerar wrote:
>
> On Wed, Aug 12, 2015 at 9:18 AM, Ladislav Thon <lthon at redhat.com
> <mailto:lthon at redhat.com>> wrote:
>
>
>     However, if there's not enough time to do everything requried, then I
>     believe that low-risk things like "remove the threads extension and the
>     threads subsystem" could be left to the user (provided that they are
>     documented).
>
>
>
> I think we could ease the threads subsystem migration.
> For most cases threads subsystem configuration is empty as it was just
> present
> in our default config as <subsystem xmlns="urn:jboss:domain:threads:1.x"/>
>
> We can change parser that in case that only empty config is present it wont
> add the subsystem at all, this should ease the migration for users
> migrating default configurations.
>

Thinking about this more, I don't think it's worthwhile.

First, doing this would make the subsystem go away, but the extension 
will still be registered, and the user will still need to remove it. 
This trick only does half the job. Until the user does the other half 
the API to re-add the subsystem is still there to confuse users 
(although we'd make sure any attempt to use it out of --admin-only 
fails) and there would still be WARN logging during boot.

Second, we wouldn't add the subsystem, but until some change to the 
config file happens causing a write, the subsystem will still be in the 
xml. That's confusing if the user notices it and violates the 
fundamental principle that the config file accurately represents the 
current in-memory config.

Finally, as I mentioned elsewhere in this thread, the cmp and jaxr 
subsystems also ship with an empty config, but they aren't good 
candidates for this treatment because with those the empty subsystem 
really means something. So there'd be different behavior between threads 
and those, for non-obvious reasons.


>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat