Major We used to treat requests to get a store with a null name as implicitly meaning get the default named store. But a recent change (JBTM-2207 Make default name null in order for quick lookup) meant that this is no longer the default behaviour. Now a request like the following
BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, null);
will return something other than the default named instance. This is causing a problem on wildfly where the call StoreManager.getRecoveryStore() does not return what was set in the transaction subsystem service initialisation.
The fix is to explicitly set the name, ie replace calls like
BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, null);
with
BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "default");
[JBTM-2307] StoreManager.getRecoveryStore() does not return the correct default
Michael Musgrove
added a comment - That usage (ArjunaObjectStoreEnvironmentService.java#L78) is indeed the culprit. So we should raise the bug against wildfly instead.
Michael Musgrove
added a comment - That usage (ArjunaObjectStoreEnvironmentService.java#L78) is indeed the culprit. So we should raise the bug against wildfly instead. 
Tom Jenkinson
added a comment - The purpose of JBTM-2207 it was to avoid string comparison with the default name - hence the default was moved to null. I would therefore think if we are going back to using a String for the default we are losing any value in 2207.
We can of course revert 2207 but in my testing it seems to work and return the same instance?
Object namedInstance = BeanPopulator.getNamedInstance(Object.class, null); Object namedInstance2 = BeanPopulator.getNamedInstance(Object.class, null); assertEquals(namedInstance, namedInstance2);
Is it possible the instance in question is being initialised by name "default" through some access that was missed?
This one for example: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/ArjunaObjectStoreEnvironmentService.java#L78 (The reason this is not a backwards compatibility issue is com.arjuna.common.internal.util.propertyservice.BeanPopulator is internal code that the app server is using)
Tom Jenkinson
added a comment - The purpose of JBTM-2207 it was to avoid string comparison with the default name - hence the default was moved to null. I would therefore think if we are going back to using a String for the default we are losing any value in 2207.
We can of course revert 2207 but in my testing it seems to work and return the same instance?
Object namedInstance = BeanPopulator.getNamedInstance( Object .class, null );
Object namedInstance2 = BeanPopulator.getNamedInstance( Object .class, null );
assertEquals(namedInstance, namedInstance2);
Is it possible the instance in question is being initialised by name "default" through some access that was missed?
This one for example: https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/ArjunaObjectStoreEnvironmentService.java#L78 (The reason this is not a backwards compatibility issue is com.arjuna.common.internal.util.propertyservice.BeanPopulator is internal code that the app server is using) 
Duplicate of https://issues.jboss.org/browse/WFLY-4132