[
https://issues.apache.org/jira/browse/TAP5-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864153#comment-17864153
]
Hendrik Noot commented on TAP5-2754:
------------------------------------
I observed this problem with the TestApp0 test application of the Hibernate
module. For example on the griddemo.setup page. I’m not certain if this is
completely deterministic. It seems that the Hibernate session is not created on
access to the injected (proxy) session object.
If it has been created before, like with the mentioned call to getSession() or
on a page that uses it before, like encodeentities/1 (loads the entity with the
id 1) it seems to work. So this is probably not an issue for applications that
use something like the OpenSessionInViewFilter from the Springframework.
> Some methods of an injected Hibernate Session return null
> ---------------------------------------------------------
>
> Key: TAP5-2754
> URL: https://issues.apache.org/jira/browse/TAP5-2754
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-hibernate
> Affects Versions: 5.7.2, 5.8.2
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Major
>
> If you inject the Hibernate Session, some calls might return null.
> Identified problematic methods are:
> * createNativeQuery
> * createQuery
> * getNamedQuery
> It possible that more methods are affected.
> Debugging the issue is complicated, as the Hibernate Session is hidden away
> behind a PropertyShadowBuilder.
> It's a property on org.apache.tapestry5.hibernate.HibernateSessionManager
> that is created in
> org.apache.tapestry5.hibernate.modules.HibernateCoreModule.buildSession(HibernateSessionManager,
> PropertyShadowBuilder)
> The reasoning for this is that the Session doesn't have to be scoped
> PerThread, as the HibernateSessionManager is, and the Session is only
> actually created on first use, not on HSM creation.
> I've debugged through the shadowing process and checked the created
> PlasticClass and underlying ClassNode, and they look good to me as all
> methods are there.
> As everything is runtime-generated bytecode, maybe a tool like
> [https://github.com/AdoptOpenJDK/jitwatch] could help to analyze what's
> actually happening.
> 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.
>
> *Current workaround:*
> Call {{getSession()}} on the injected Session, the method will then work as
> intended.
>
> *Maybe related ticket:*
> https://issues.apache.org/jira/browse/TAP5-2582
>
> *Related mailing list threads:*
> [https://lists.apache.org/thread/r4bhr01d95kpl8pslrhr1bdx486b29nd]
> [https://lists.apache.org/thread/qwc6430qq0f4nt7oc755z443c2zh6j68]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
