nizhikov opened a new pull request, #13799: URL: https://github.com/apache/ignite/pull/13799
https://issues.apache.org/jira/browse/IGNITE-29259 `BinaryContext#configure` resolved the class of every `BinaryTypeConfiguration` entry with `ClassLoaderUtils.classForName`, i.e. through the loader Ignite itself was loaded by, ignoring `IgniteConfiguration#setClassLoader`. For a class visible only through the configured loader the `@AffinityKeyMapped` field was not detected. `registerUserType`, called right after for the same type, did find the class through the configured loader and registered the descriptor and metadata with a `null` affinity key field. The descriptor is cached, so marshalling an instance later did not repair it. Result: the same key class got its affinity key field detected when the type was not listed in `BinaryConfiguration#setTypeConfigurations` and lost it when it was listed. Fix: a private `loadClassOrNull` helper resolves through the configured loader; `configure` and `registerUserType` both use it. Test: `BinaryTypeConfigurationCustomClassLoaderTest` loads a new `CacheDeploymentAffinityMappedKey` from `extdata/p2p` through `GridTestExternalClassLoader`, sets that loader as `IgniteConfiguration#setClassLoader` and checks `affinityKeyFieldName()` with and without a `BinaryTypeConfiguration` for the class. The configured case fails on master with `expected:<aff> but was:<null>`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
