mihxil opened SPR-17311 and commented
I tried to upgrade my project using spring and hibernate to spring 5.1.
I use customized search mappings via org.hibernate.search.cfg.SearchMapping and have some instances were we customize a bridge via org.hibernate.search.cfg.FieldMapping#bridge.
I noticed that the classes I supply there must now be instantiated with spring. This surprised me a bit, but well.
The issue arises if the class is also a org.hibernate.search.bridge.ParameterizedBridge, and we set some 'params' (org.hibernate.search.cfg.FieldBridgeMapping#param)
Different fields with the same bridge implementation but with different params, now receive the same instance of the class, so things gets mixed up. The param of one field influences the behaviour of another field.
It boils down to that parameterized bridges get unusable. The first thought was, since the instance are now managed by spring, that I could also configure them there, but it seems that they are matched on class only, so I have to extend the bridge for every instance with different params, more or less mooting the complete point of parametrization.
It could be that I missed something, but I couldn't easily find out what that would be.
Affects: 5.1 GA
Comment From: spring-projects-issues
Juergen Hoeller commented
Not sure whether the bug is in Hibernate 5.3's handling of the BeanContainer SPI or in Spring's SpringBeanContainer implementation... Could you try to debug the latter and see which callback you get for your beans (that seem to end up at the same instance)?
Comment From: jhoeller
Closing this since we are not aware of any misbehavior on Spring's end. Note that SpringBeanContainer has been revised quite a bit, so in case there is still an issue here, please confirm it against the latest 6.0.11 release (which includes #30683).