I've tried to debug the issue again, but to no avail :-/ Here are my observations/findings/notes:
The Session you get injected is actually a shadowed property of org.apache.tapestry5.hibernate.HibernateSessionManager that is created in org.apache.tapestry5.hibernate.modules.HibernateCoreModule.buildSession(HibernateSessionManager, PropertyShadowBuilder) The PropertyShadowBuilder creates a proxy of a single property of a source object, and delegates all calls to the source object when used. This allows the shadowed property, in this case Session, to be extracted from the source, HibernateSessionManager, and used as an isolated instance. Behind the scenes, though, it's still the session of a HSM. This is done so the HSM can be per-Thread scoped and only create a session if it's actually used. I've debugged through the shadowing process and checked the created PlasticClass and underlying ClassNode, and they look good to me. As everything is runtime-generated bytecode, maybe a tool like https://github.com/AdoptOpenJDK/jitwatch could help to analyze what's actually happening. But so far, I only got Eclipse to run out of heap space... My guess is that the big changes starting Hibernate 5.2 (moving towards javax.persistence, like Session now extending javax.persistence.EntityManager and org.hibernate.jpa.HibernateEntityManage) are not 100% compatible with what Plastic/PropertyShadowBuilder are doing behind the scenes. It's not completely broken, but certain things seem to work a little differently. On Fri, Jun 9, 2023 at 7:07 PM Vangel V. Ajanovski <ajanov...@gmail.com> wrote: > On 9.6.23 14:30, Ben Weidig wrote: > > we ran into similar issues with custom queries, our workaround is calling > > getSession() on the session, like this: > > > > return this.session.getSession().createQuery(sql) // > > .setParameter("replyToId", relatedId) // > > .setParameter("type", type) // > > .executeUpdate(); > > > Hi, I have the same issue since 5.7.3 -- I encountered the issue in a > different context and discussed it briefly here in that context when > 5.7.3 was released. > > The problem and solution is the same: > > @Inject private Session session; > > session.createQuery("from Table") > > fails as createQuery returns null > > On the other hand > > session.getSession().createQuery("from Table") > > works without issues. > > > Who knows maybe there is some other consequence of using > session.getSession(). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
