You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Christopher Dodunski (Tapestry)" <Ch...@christopher.net.nz> on 2023/06/09 11:43:38 UTC
Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Hello,
I've encountered an issue after upgrading from Tapestry 5.6.4 to 5.7.3.
This included moving from Hibernate 5.1.0.Final to 5.4.32.Final (as per
the guidelines).
The HibernateCrudServiceDAO method below is now failing to fetch named
queries via the injected org.hibernate.Session, resulting in a null
pointer exception when attempting to write parameters to it.
I'm wondering whether this might have something to do with
org.hibernate.Query having been deprecated and replaced with
org.hibernate.query.Query. I understand the tapestry-hibernate package
was reworked around the time of Tapestry 5.7.3 to support changes in
Hibernate.
Incidentally, the issue remains with Tapestry 5.8.2.
Any help/insights would be much appreciated.
Thanks & regards,
Chris.
import org.hibernate.query.Query;
import org.hibernate.Session;
...
@Inject
private Session session;
...
public <T> T findUniqueWithNamedQuery(String queryName, Map<String,
Object> params){
Set<Entry<String, Object>> rawParameters = params.entrySet();
Query query = session.getNamedQuery(queryName);
if(query == null) LOG.error("Oops, Hibernate session returned
null Query object!");
if(query != null) LOG.debug("Query string = " +
query.getQueryString());
for(Entry<String, Object> entry : rawParameters){
LOG.debug("Entry key = " + entry.getKey());
LOG.debug("Entry value = " + entry.getValue().toString());
query.setParameter(entry.getKey(), entry.getValue());
}
return (T) query.uniqueResult();
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Volker Lamp <vl...@apache.org>.
Hi Vangel
> Is this because the bug only occurs in some very specific environments
> (only some specific OS and some specific JDK combination and some
> specific DB driver), or tapestry-hibernate is not in use any more by
> committers and other developers and tapestry-jpa is the preferred way,
> or both are obsolete nowadays and one should pursue some other approach
> to persistence when using Tapestry?
We have two Tapestry apps in production. One uses tapestry-hibernate, but is still on Tapestry 5.5, so out of the scope of the problem you described. The other one uses tapestry-jpa, therefore also not relevant. I think both work very well, at least for us, but I acknowledge others, including you, are experiencing difficulties in some setups. Keen to find the cause and fix it.
Thanks,
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Hello, everyone!
While I believe we should fix this problem in the Tapestry's proxy
creator code, since it may have been happening in non-Hibernate stuff
as well, maybe we could have an interim fix of not using
PropertyShadowBuider to build the Session service? Code is in
HibernateCoreModule.buildSession().
On Sat, Jun 24, 2023 at 11:17 AM Ben Weidig <be...@netzgut.net> wrote:
>
> I think I found the issue.
> Not 100% sure yet, but my first tests look good.
>
> The PropertyShadowBuilder got changed in TAP5-2582, so it can handle
> duplicate methods if interfaces extend each other.
>
>
> In the case of Session, however, the return types of the methods differ, as
> it's totally valid to elevate a return type if you extend an interface, as
> long as the new return type extends/implements the previous one.
> The
> org.apache.tapestry5.ioc.internal.services.PropertyShadowBuilderImpl.MethodSignatureUniqueComparator
> is used for sorting the methods, so only the first of each method is used.
>
>
> For example,without checking the return type, the method
>
> public abstract org.hibernate.query.Query
> org.hibernate.SharedSessionContract.getNamedQuery(java.lang.String)
>
> gets removed.
>
>
>
> With comparing return types, the method
>
> public default org.hibernate.Query
> org.hibernate.SharedSessionContract.getNamedQuery(java.lang.String)
>
> gets removed.
>
>
> What confused me was the "default" modifier on the method, as the method
> declarations in the interface don't have a "default" implementations.
> Let's recreate the scenario:
>
> interface Original {
> Number test();
> }
> interface Extended extends Original {
> Double test();
> }
>
> Time for some bytecode:
>
> Classfile /Users/ben/code/tapestry/tapestry-5/Extended.class
> Last modified 24 Jun 2023; size 254 bytes
> SHA-256 checksum
> 708c3793a9074f5afdd523542cf287559d5cbeee871a0ca9757444dc28edafe3
> Compiled from "Extended.java"
> interface Extended extends Original
> minor version: 0
> major version: 61
> flags: (0x0600) ACC_INTERFACE, ACC_ABSTRACT
> this_class: #2 // Extended
> super_class: #7 // java/lang/Object
> interfaces: 1, fields: 0, methods: 2, attributes: 1
> Constant pool:
> #1 = InterfaceMethodref #2.#3 //
> Extended.test:()Ljava/lang/Double;
> #2 = Class #4 // Extended
> #3 = NameAndType #5:#6 // test:()Ljava/lang/Double;
> #4 = Utf8 Extended
> #5 = Utf8 test
> #6 = Utf8 ()Ljava/lang/Double;
> #7 = Class #8 // java/lang/Object
> #8 = Utf8 java/lang/Object
> #9 = Class #10 // Original
> #10 = Utf8 Original
> #11 = Utf8 ()Ljava/lang/Number;
> #12 = Utf8 Code
> #13 = Utf8 LineNumberTable
> #14 = Utf8 SourceFile
> #15 = Utf8 Extended.java
> {
> public abstract java.lang.Double test();
> descriptor: ()Ljava/lang/Double;
> flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
>
> public default java.lang.Number test();
> descriptor: ()Ljava/lang/Number;
> flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
> Code:
> stack=1, locals=1, args_size=1
> 0: aload_0
> 1: invokeinterface #1, 1 // InterfaceMethod
> test:()Ljava/lang/Double;
> 6: areturn
> LineNumberTable:
> line 1: 0
> }
> SourceFile: "Extended.java"
>
> Ok, the "default" method now makes more sense, as the two methods exist on
> the interface but with different return types.
> This might feel like invalid Java, as the return type doesn't count to the
> method signature, but the JVM allows that.
> The ACC_BRIDGE flag means that the method was generated by the compiler to
> "bridge" between the original method declaration and the override.
>
>
> With that knowledge, my hunch is that even though the default method, which
> should call the correct method, can't because, well, Proxies do a lot of
> bytecode magic themselves.
>
>
> On Fri, Jun 23, 2023 at 8:22 PM Vangel V. Ajanovski <aj...@gmail.com>
> wrote:
>
> > On 21.6.23 20:32, Volker Lamp wrote:
> > > Is there any chance I can motivate you to contribute your test case as
> > > a unit test to the Tapestry code base? Have a look at the test apps in
> > > tapestry-jpa as a starting point.
> >
> > If I find some free time in the following months to look it up and learn
> > how to create an entire test case. For the time-being it will be faster
> > for me to create a docker container spec to reproduce the bug.
> >
> > As an alternative, I tried to modify the tapestry sources and the
> > existing tests. I have never tried to build tapestry from source in the
> > past, so bare with my ignorance. I cloned the sources from git, and
> > decided for the command line route and just did ./gradlew build.
> >
> > It seems successful. All the .jars are at the expected locations. I
> > modified the gradle build file and hibernate.cfg.xml in the test folders
> > inside tapestry-hibernate so that it should connect to another database
> > and it uses another driver, just to see if this will stir things up, but
> > nothing happened. The problem is that I don't see any connections to the
> > database when I run the build, which seems strange to me. How do I force
> > the tests to rerun and which is the specific test that i should run that
> > uses the connection information in
> > tapestry-hibernate/src/test/resources/hibernate.cfg.xml?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Ben Weidig <be...@netzgut.net>.
I think I found the issue.
Not 100% sure yet, but my first tests look good.
The PropertyShadowBuilder got changed in TAP5-2582, so it can handle
duplicate methods if interfaces extend each other.
In the case of Session, however, the return types of the methods differ, as
it's totally valid to elevate a return type if you extend an interface, as
long as the new return type extends/implements the previous one.
The
org.apache.tapestry5.ioc.internal.services.PropertyShadowBuilderImpl.MethodSignatureUniqueComparator
is used for sorting the methods, so only the first of each method is used.
For example,without checking the return type, the method
public abstract org.hibernate.query.Query
org.hibernate.SharedSessionContract.getNamedQuery(java.lang.String)
gets removed.
With comparing return types, the method
public default org.hibernate.Query
org.hibernate.SharedSessionContract.getNamedQuery(java.lang.String)
gets removed.
What confused me was the "default" modifier on the method, as the method
declarations in the interface don't have a "default" implementations.
Let's recreate the scenario:
interface Original {
Number test();
}
interface Extended extends Original {
Double test();
}
Time for some bytecode:
Classfile /Users/ben/code/tapestry/tapestry-5/Extended.class
Last modified 24 Jun 2023; size 254 bytes
SHA-256 checksum
708c3793a9074f5afdd523542cf287559d5cbeee871a0ca9757444dc28edafe3
Compiled from "Extended.java"
interface Extended extends Original
minor version: 0
major version: 61
flags: (0x0600) ACC_INTERFACE, ACC_ABSTRACT
this_class: #2 // Extended
super_class: #7 // java/lang/Object
interfaces: 1, fields: 0, methods: 2, attributes: 1
Constant pool:
#1 = InterfaceMethodref #2.#3 //
Extended.test:()Ljava/lang/Double;
#2 = Class #4 // Extended
#3 = NameAndType #5:#6 // test:()Ljava/lang/Double;
#4 = Utf8 Extended
#5 = Utf8 test
#6 = Utf8 ()Ljava/lang/Double;
#7 = Class #8 // java/lang/Object
#8 = Utf8 java/lang/Object
#9 = Class #10 // Original
#10 = Utf8 Original
#11 = Utf8 ()Ljava/lang/Number;
#12 = Utf8 Code
#13 = Utf8 LineNumberTable
#14 = Utf8 SourceFile
#15 = Utf8 Extended.java
{
public abstract java.lang.Double test();
descriptor: ()Ljava/lang/Double;
flags: (0x0401) ACC_PUBLIC, ACC_ABSTRACT
public default java.lang.Number test();
descriptor: ()Ljava/lang/Number;
flags: (0x1041) ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokeinterface #1, 1 // InterfaceMethod
test:()Ljava/lang/Double;
6: areturn
LineNumberTable:
line 1: 0
}
SourceFile: "Extended.java"
Ok, the "default" method now makes more sense, as the two methods exist on
the interface but with different return types.
This might feel like invalid Java, as the return type doesn't count to the
method signature, but the JVM allows that.
The ACC_BRIDGE flag means that the method was generated by the compiler to
"bridge" between the original method declaration and the override.
With that knowledge, my hunch is that even though the default method, which
should call the correct method, can't because, well, Proxies do a lot of
bytecode magic themselves.
On Fri, Jun 23, 2023 at 8:22 PM Vangel V. Ajanovski <aj...@gmail.com>
wrote:
> On 21.6.23 20:32, Volker Lamp wrote:
> > Is there any chance I can motivate you to contribute your test case as
> > a unit test to the Tapestry code base? Have a look at the test apps in
> > tapestry-jpa as a starting point.
>
> If I find some free time in the following months to look it up and learn
> how to create an entire test case. For the time-being it will be faster
> for me to create a docker container spec to reproduce the bug.
>
> As an alternative, I tried to modify the tapestry sources and the
> existing tests. I have never tried to build tapestry from source in the
> past, so bare with my ignorance. I cloned the sources from git, and
> decided for the command line route and just did ./gradlew build.
>
> It seems successful. All the .jars are at the expected locations. I
> modified the gradle build file and hibernate.cfg.xml in the test folders
> inside tapestry-hibernate so that it should connect to another database
> and it uses another driver, just to see if this will stir things up, but
> nothing happened. The problem is that I don't see any connections to the
> database when I run the build, which seems strange to me. How do I force
> the tests to rerun and which is the specific test that i should run that
> uses the connection information in
> tapestry-hibernate/src/test/resources/hibernate.cfg.xml?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Vangel V. Ajanovski" <aj...@gmail.com>.
On 21.6.23 20:32, Volker Lamp wrote:
> Is there any chance I can motivate you to contribute your test case as
> a unit test to the Tapestry code base? Have a look at the test apps in
> tapestry-jpa as a starting point.
If I find some free time in the following months to look it up and learn
how to create an entire test case. For the time-being it will be faster
for me to create a docker container spec to reproduce the bug.
As an alternative, I tried to modify the tapestry sources and the
existing tests. I have never tried to build tapestry from source in the
past, so bare with my ignorance. I cloned the sources from git, and
decided for the command line route and just did ./gradlew build.
It seems successful. All the .jars are at the expected locations. I
modified the gradle build file and hibernate.cfg.xml in the test folders
inside tapestry-hibernate so that it should connect to another database
and it uses another driver, just to see if this will stir things up, but
nothing happened. The problem is that I don't see any connections to the
database when I run the build, which seems strange to me. How do I force
the tests to rerun and which is the specific test that i should run that
uses the connection information in
tapestry-hibernate/src/test/resources/hibernate.cfg.xml?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Volker Lamp <vl...@apache.org>.
Hi Vangel
> For me, it is very easy to reproduce. I can share the entire source
> code, but there is nothing special to share.
Thank you for the code example!
Is there any chance I can motivate you to contribute your test case as a unit test to the Tapestry code base? Have a look at the test apps in tapestry-jpa as a starting point.
Thank you,
Volker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Vangel V. Ajanovski" <aj...@gmail.com>.
On 15.6.23 14:17, Thiago H. de Paula Figueiredo wrote:
> Yeah, it doesn't seem to happen for everyone. tapestry-hibernate has
> unit and integration tests and they have been successful.
For me, it is very easy to reproduce. I can share the entire source
code, but there is nothing special to share.
I start with the tapestry quick-start, add tapestry-hibernate and
postgresql driver in the pom.xml, add just one entity class named Book
(id, title and description and respective getter/setters) and modify the
About page to be really simple:
import java.util.List;
import org.apache.tapestry5.ioc.annotations.Inject;
import org.hibernate.Session;
import test.testhql.entities.Book;
public class TestPage {
@Inject
private Session session;
public List<Book> getListOfBooks() {
// this does not work
return session.createQuery("from Book").list();
// this works
//return session.getSession().createQuery("from Book").list();
// this works too
//return session.createCriteria(Book.class).list();
}
}
And the result is an error with this as the main problem:
Caused by: java.lang.NullPointerException: Cannot invoke
"org.hibernate.query.Query.list()" because the return value of
"org.hibernate.Session.createQuery(String)" is null
The rest of the code:
TML File:
<html t:type="layout" title="About | testhql"
xmlns:t="http://tapestry.apache.org/schema/tapestry_5_4.xsd"
xmlns:p="tapestry:parameter">
<t:grid t:source="listOfBooks" />
</html>
Entity class:
package test.testhql.entities;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
@Entity
@Table(name = "book", schema = "public")
public class Book {
private long bookId;
private String title;
private String description;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "book_id", unique = true, nullable = false)
public long getBookId() {
return bookId;
}
public void setBookId(long bookId) {
this.bookId = bookId;
}
@Column(name = "title", unique = false, nullable = false)
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
@Column(name = "description", unique = false, nullable = true,
length = 10000000)
public String getDescription() {
return description;
}
public void setDescription(String description) {
this.description = description;
}
}
in case it matters:
The results is the same if I run the app from Eclipse flatpak (on Fedora
Silverblue, so should be reproducible), or if I run it from a
commandline using SDKMAN managed Maven and JDK.
Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: ~/.sdkman/candidates/maven/current
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
~/.sdkman/candidates/java/17.0.6-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.3.7-200.fc38.x86_64", arch: "amd64",
family: "unix"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Hello, everyone!
On Sun, Jun 11, 2023 at 2:04 PM Vangel V. Ajanovski <aj...@gmail.com> wrote:
> This bug prompts another question that bothers me.
>
> How come nobody else has noticed the bug for two years? I had a report
> in Sep 2021, which did not get an answer, there is another mention on
> Stack Overflow in the last month and now this thread here opened by Chris.
Well, I work with a fairly large project which uses tapestry-hibernate
and Hibernate a lot, in both web and non-web (typically, Quartz jobs,
but not only that) and I haven't run into this problem yet.
> Is this because the bug only occurs in some very specific environments
> (only some specific OS and some specific JDK combination and some
> specific DB driver),
Yeah, it doesn't seem to happen for everyone. tapestry-hibernate has
unit and integration tests and they have been successful.
> or tapestry-hibernate is not in use any more by
> committers and other developers and tapestry-jpa is the preferred way,
tapestry-hibernate is in use by the committers. There's no preference
for it over tapestry-jpa nor the other way around.
> or both are obsolete nowadays and one should pursue some other approach
> to persistence when using Tapestry?
That's definitely not the case.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Chris Poulsen <ma...@nesluop.dk>.
>
> How come nobody else has noticed the bug for two years?
>
In general we're isolating the use of Tapestry to our presentation layer -
The datastore access (and business logic) lives in modules and the UI sits
on top of the business logic layer - The lower level modules are usually
wired up with Spring IoC and we bridge the two IoC systems, so Tapestry can
see/inject Spring services, but the opposite is not true.
With a traditional layering like that we never need to access the datastore
directly from Tapestry code - so a lot of the magic Tapestry
modules/features are not in play (like hibernate integration etc).
--
Chris
On Sun, Jun 11, 2023 at 7:04 PM Vangel V. Ajanovski <aj...@gmail.com>
wrote:
> This bug prompts another question that bothers me.
>
> How come nobody else has noticed the bug for two years? I had a report
> in Sep 2021, which did not get an answer, there is another mention on
> Stack Overflow in the last month and now this thread here opened by Chris.
>
> Is this because the bug only occurs in some very specific environments
> (only some specific OS and some specific JDK combination and some
> specific DB driver), or tapestry-hibernate is not in use any more by
> committers and other developers and tapestry-jpa is the preferred way,
> or both are obsolete nowadays and one should pursue some other approach
> to persistence when using Tapestry?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Vangel V. Ajanovski" <aj...@gmail.com>.
This bug prompts another question that bothers me.
How come nobody else has noticed the bug for two years? I had a report
in Sep 2021, which did not get an answer, there is another mention on
Stack Overflow in the last month and now this thread here opened by Chris.
Is this because the bug only occurs in some very specific environments
(only some specific OS and some specific JDK combination and some
specific DB driver), or tapestry-hibernate is not in use any more by
committers and other developers and tapestry-jpa is the preferred way,
or both are obsolete nowadays and one should pursue some other approach
to persistence when using Tapestry?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Ben Weidig <be...@netzgut.net>.
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 <aj...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by "Vangel V. Ajanovski" <aj...@gmail.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Problem running Tapestry 5.8.2 with Hibernate 5.4.32.Final
Posted by Ben Weidig <be...@netzgut.net>.
Hi Chris,
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();
It's ugly and the call is deprecated, but it worked for us.
We never really looked into it, though, as we usually don't use Hibernate
via named/custom queries that much.
My guess would be that something changed in the Hibernate session,
and org.apache.tapestry5.hibernate.modules.HibernateCoreModule.buildSession(HibernateSessionManager,
PropertyShadowBuilder) doesn't work as initially intended anymore.
Cheers
Ben
On Fri, Jun 9, 2023 at 1:43 PM Christopher Dodunski (Tapestry) <
ChrisFromTapestry@christopher.net.nz> wrote:
> Hello,
>
> I've encountered an issue after upgrading from Tapestry 5.6.4 to 5.7.3.
> This included moving from Hibernate 5.1.0.Final to 5.4.32.Final (as per
> the guidelines).
>
> The HibernateCrudServiceDAO method below is now failing to fetch named
> queries via the injected org.hibernate.Session, resulting in a null
> pointer exception when attempting to write parameters to it.
>
> I'm wondering whether this might have something to do with
> org.hibernate.Query having been deprecated and replaced with
> org.hibernate.query.Query. I understand the tapestry-hibernate package
> was reworked around the time of Tapestry 5.7.3 to support changes in
> Hibernate.
>
> Incidentally, the issue remains with Tapestry 5.8.2.
>
> Any help/insights would be much appreciated.
>
> Thanks & regards,
>
> Chris.
>
>
> import org.hibernate.query.Query;
> import org.hibernate.Session;
> ...
> @Inject
> private Session session;
> ...
> public <T> T findUniqueWithNamedQuery(String queryName, Map<String,
> Object> params){
> Set<Entry<String, Object>> rawParameters = params.entrySet();
> Query query = session.getNamedQuery(queryName);
>
> if(query == null) LOG.error("Oops, Hibernate session returned
> null Query object!");
> if(query != null) LOG.debug("Query string = " +
> query.getQueryString());
>
> for(Entry<String, Object> entry : rawParameters){
> LOG.debug("Entry key = " + entry.getKey());
> LOG.debug("Entry value = " + entry.getValue().toString());
> query.setParameter(entry.getKey(), entry.getValue());
> }
>
> return (T) query.uniqueResult();
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>