I'm currently working through an upgrade from 2.25 to 2.26, and ran into something which - while I was able to determine a workaround - may actually be a pretty significant bug. The release notes pointed me at this list, and I figured I would ask here first before filing a ticket, just in case this was by design.
The issue arose when, in my case, I attempt to bind hibernate's `FullTextSession implements Session` and a regular Session as DisposingSuppliers, via the new internal AbstractBinder. The binders look like this:
.to(FullTextSession.class) // implements Session
The interesting bit is that FulltextSessionFactory requires a regular Session, which is where the trouble begins. Whenever the FulltextSessionFactory is constructed, it attempts to resolve the Session dependency, and thinks that FullTextSession satisfies that contract. Result: StackOverflowError due to recursive dependency resolution.
Now, my current workaround is that I've added a contract to the first Supplier, which is the underlying SessionImpl, and made the second supplier depend on that; this seems to work. Having said that... this worked in 2.25.4, and it seems a little odd that - when I explicitly bind something to a particular class - it generates both my explicitly declared contract, as well as magically creating a contract for the implemented interfaces.
So my question is:
- Is this by design?
- If so, is there a way that I can bind a Supplier to one, and only one, class?