[wildfly-dev] Easing migration beyond the migration ops
Brian Stansberry
brian.stansberry at redhat.com
Wed Aug 12 17:01:40 EDT 2015
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
More information about the wildfly-dev
mailing list