[WFLY-5520] More re: default-clustered-sfsb-cache, default-sfsb-cache

[bstansberry]

@pferraro @rhusar @n1hility @Ladicek WDYT? Wall of text begins...

In EAP 7 the meaning of the ejb3 subsystem default-sfsb-cache attribute has changed vs EAP 6.4, with another attribute, default-clustered-sfsb-cache deprecated and it's functionality mapped to the repurposed default-sfsb-cache and finally a third attribute introduced, default-sfsb-passivation-disabled-cache, whose semantics are the same as the EAP 6.4 meaning of default-sfsb-cache.

Translation Table
EAP 6.4                                                EAP 7.0

default-clustered-sfsb-cache → default-sfsb-cache
default-sfsb-cache           → default-sfsb-passivation-disabled-cache
N/A                            default-sfsb-passivation-disabled-cache

See description of #8481 for more on the validity of this mapping.

These changes introduce some compatibility and migration challenges, with various fixes trying to deal with these, but problems still remain. So I wanted to be very thorough and try to slay this beast.

Hard requirements:

1. EAP 6.2+ standalone.xml documents can be used to boot an EAP 7 server (JBEAP-2014)
2. EAP 6.2+ domain.xml profiles can be used by EAP 7 DC to manage EAP 6 slaves
3. EAP 6.2+ CLI scripts or text operation descriptions can be used perform a read of the default-sfsb-cache attribute, with response results consistent with EAP 7 runtime behavior
4. In any EAP 7 server config, if default-clustered-sfsb-cache is defined, its value must match that of default-sfsb-cache. This is because the server does not use default-clustered-sfsb-cache in the runtime, so if it has an different value from default-sfsb-cache it means somehow the server has gotten an ambiguous configuration.
5. Admin console correctly configures the subsystem in all cases

Nice-to-have Requirements

1. EAP 6.2+ CLI scripts or text operation descriptions can be used add the EJB3 subsystem to an EAP 7 server
2. EAP 6.2+ CLI scripts or text operation descriptions can be used add the EJB3 subsystem to an EAP 7 DC
3. EAP 6.2+ CLI scripts or text operation descriptions can be used perform a write-attribute of the default-clustered-sfsb-cache attribute, with runtime results consistent with EAP 6.x behavior
4. EAP 6.2+ CLI scripts or text operation descriptions can be used perform a write-attribute of the default-sfsb-cache attribute, with runtime results consistent with EAP 6.x behavior
5. EAP 6.2+ CLI scripts or text operation descriptions can be used perform a read of the default-clustered-sfsb-cache attribute, with response results consistent with EAP 6.x runtime behavior

Not Possible

1. EAP 6.2+ CLI scripts or text operation descriptions can be used perform a read of the default-sfsb-cache attribute, with response results consistent with EAP 6.x runtime behavior. This is not possible because it is a contradiction of Hard Requirement Provide management view on the ServiceContainer #3.

The existence of “Not Possible #1” argues that “Nice-to-have #4” is a bad idea, since if you can do a write-attribute you would expect a consistent read-attribute.

Not doing “Nice-to-have #4” argues that “Nice-to-have #3” is a bad idea, since to an EAP 6.2+ user the two attributes were a pair. Being able to write default-clustered-sfsb-cache with EAP 6 semantics but then default-sfsb-cache has EAP 7 semantics would be confusing.

This confusion is lessened though in the case of add operations (“Nice-to-have #1 and #2”) as the presence of both parameters in the same operation provides useful context as to user intent.

Proposal:

1. XML parsers for legacy schemas do not do any translation when creating add operations – they convert xml attributes to parameters same as they did in legacy releases. All translation is done in 4) below. (This is the current behavior.)
2. EJB3 subsystem in a Domain Controller uses a transformer to perform the reverse of what's shown in Translation Table above when managing a legacy slave.
3. The default-clustered-sfsb-cache attribute is made read-only, and simply returns the value of default-sfsb-cache. This change to read-only is an API break.
4. The handler of the /subsystem=ejb3:add operation checks for the presence of the default-clustered-sfsb-cache param. If present it interprets the operation as being from a legacy script, and remaps the default-clustered-sfsb-cache and default-sfsb-cache params per the Translation Table.
   4.1) In case of ambiguity in the add operation (i.e. all three params set with inconsistent values) then the operation should fail
   4.2) The default-clustered-sfsb-cache param value will not be directly stored in the model.
   4.3) This translation should be result in INFO logging informing the user as to what is happening

This solution meets Hard Requirements 1-4. It also allows Nice-to-have 1, 2 and 5. Nice-to-have 3 and 4 are not supported.

Hard Requirement 5 (console) is fine because default-clustered-sfsb-cache is not exposed by the console.

[Ladicek]

It might have been easiest to not change the meaning of the attributes at all. I don't think it provides that much of a value. That said, I also see why you wanted to do the change, and it's been in WildFly for some time, so reverting now would be even more of a mess.

The solution described by Brian works for me. We'll have to make sure that it's mentioned in the documentation, though.

[rhusar]

@emmartins BTW you might want to take this for a spin to see how that plays with the migration tool and please revert the workaround currently we have in the tool for this issue.

[bstansberry]

I forgot "4.3) This translation should be result in INFO logging informing the user as to what is happening" -- I'll update the PR.

[n1hility]

retest this please

[pferraro]

👍 This looks good to me.