BBA4
Registering a
Registering a PersistenceTypeResolver is ignored if executeTypeHandlerRegistration is called first
#292
Comments
|
The described behavior is caused by the current foundation implementations. As soon as a component requires a second component for its initialization that second one is created using the default implementation if not set before. If such a second component is replaced by a custom one, it won’t be used by already initialized components. As workaround disabling the automatic initialization and doing a custom initialization that takes care of the required order is the best option. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment Details
1.4.021Describe the bug
I'm developing some custom persistence for Kotlin classes that are normally not handled because they are synthetic (ones that are less ambiguous than Java anonymous classes). To do that, I create a custom
PersistenceTypeResolverwrapping the default and register it usingPersistenceFoundation::setTypeResolver. Unfortunately, this didn't work right away because of some confusing behavior.I was using the Spring Boot integration, and it defaults to
org.eclipse.store.register-jdk17-handlers=true, which means before I even received theEmbeddedStorageFoundation<?>from theEmbeddedStorageFoundationFactoryit had a type handler silently registered. It took a few minutes to track down whytypeResolverwasn't updating, but once I traced the source of the defaultPersistenceTypeResolverit led directly to that initial call toexecuteTypeHandlerRegistration.I worked around the issue by disabling automatic registration of handlers (JDK 8 and 17), doing my custom initialization with
setTypeResolver, and then manually calling.onConnectionFoundation(BinaryHandlersJDK{8,17}::registerJDK{8,17}TypeHandlers)along with my other custom type handlers.To Reproduce
Register a custom type resolver after registering a custom type handler and log what type resolver is used - it will be the default type resolver instead of the custom one.
Expected behavior
Type handlers shouldn't just make a copy of whatever the current type resolver was when they were created. Off the top of my head, they could either look that up whenever needed by referencing the foundation, or have some kind of "baking" step where they copy over everything they need when the
EmbeddedStorageFoundation<?>is done being set up. I suppose it depends on the performance implications if the results aren't cached.This seems similar to #204 and #203 (comment)
The text was updated successfully, but these errors were encountered: