Superseded by #10192

For reference WildFly is still seeing the same TCK failures with Hibernate ORM 6.6.17.Final which I think includes #10192

Is it expected that the changes in #10075 are included in pull/10192?

My other question is whether there are any identified problems with #10075?

For reference WildFly is still seeing the same TCK failures with Hibernate ORM 6.6.17.Final which I think includes #10192

Hey Scott, yeah that is expected since Christian's PR doesn't include the classloader / class source change Andrea did here.

I believe we'd prefer clarifying the topic of why the same class is loaded from different sources in wildfly first, then think of possible workarounds if really necessary on the Hibernate side.

@mbladel I think we should log the needed information. So far, I have not identified why and from where exactly the wrong classloader is used. I now have a WildFly reproducer that I want to reduce further. I also would like to instrument the org.hibernate.property.access.spi.SetterMethodImpl to show classloader information for the Object target parameter and the @Nullable Object value.

I tried adding the below code but the compiler didn't like me adding it to line 104:

				if (value != null) {
					LOG.info("xxx Thread.currentThread().getContextClassLoader() " + Thread.currentThread().getContextClassLoader());
				}
				final Class<?> expectedType = setterMethod.getParameterTypes()[0];

				LOG.info("xxx SetterMethodImpl IllegalArgumentException expectedType classloader = " +
							expectedType.getClassLoader());
				LOG.info("xxx SettMethodImpl containerClass classloader = " + containerClass.getClassLoader());

Is ^ the type of classloader information that we need?