StackOverFlowError in 2.26 Injection

Michael Krotscheck
 

Urm... hi!

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:

bindFactory(HibernateSessionFactory.class)
    .to(Session.class) 
    .in(RequestScoped.class);

bindFactory(FulltextSessionFactory.class)
    .to(FullTextSession.class) // implements Session
    .in(RequestScoped.class);

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?

Michael

Join jersey@javaee.groups.io to automatically receive all group messages.