I am upgrading Hibernate from 5.1.17 to 5.4.11. I am getting org.hibernate.LazyInitializationException while running Junit on collection whose fetch type is LAZY. I am trying to find different ways to make it work and run it in transaction(still facing some issues). Before that I would like to know what is changed after 5.1.17 which is causing this issue because earlier Junit test cases were working perfectly fine.
So what are the things changed related to lazy loading after 5.1.17?
Many things changed, so it's hard to say. What I suggest is, start upgrading your hibernate by updating 1 minor version at a time (according to https://semver.org).
Once you pinpoint which minor version is causing a problem, check:
https://hibernate.org/orm/releases/
Hope that helps.
Related
I have this strange error, the code is working, but the queryone is strange anyway and annoy. Thanks - hoping there is a solution
I searched almost everywhere for a solution, I didn't find anything helpful
Hibernate 6 expects implicit SELECT clause in front now, however the old query still compiles, it is recommended now to add SELECT as well.
SELECT e FROM Employee e
EntityManager autowiring error is most likely only because of IntelliJ cannot find the correct configuration for this bean, but should work fine at runtime.
This error is coming from your IDE, or more precisely from some IDE plugin.
I don't know what plugin you're using, but I imagine that the plugin is validating that the query is syntactically correct JPQL, and is not accepting one of HQL's many extensions to the syntax of JPQL.
Your query is perfectly legal HQL, for the record.
I am facing the following problem. Using a compiled software I am trying to launch it on Tomcat 8 instead of Tomcat 7. After resolving some minor problems I get stuck at this one:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ... Invocation of init method failed; nested exception is java.lang.IncompatibleClassChangeError: Found class org.objectweb.asm.AnnotationVisitor, but interface was expected
Reading around, it seems like it comes from Spring version difference. Trouble is I'm not touching the application here at all. Tomcat 7 and Tomcat 8 get exactly same program to launch.
Could I ask you for your suggestions on solving it?
On the way of investigating the problem I've learned about this ticket: https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
It looks like Tomcat 8, as opposed to earlier Tomcat version does not load classes alphabetically. In my project it caused a problem as libraries holding different versions of asm where used.
Note: In the ticket from above - raised to apache, someone links the workaround at https://github.com/openwide-java/tomcat-classloader-ordered. For me it did not work, though.
In the end we had to go through a complex work of removing dependencies and fixing the project up so that it relies on one lib version only.
Good luck for everyone struggling with similar stuff!
I'm using Hibernate 4.1.8.Final/Spring 3.1 and getting the following exception:
java.lang.NullPointerException
at org.hibernate.event.internal.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushin$
at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(Abstract$
at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventLis$
at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1185)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1240)
It may be an open bug in Hibernate 4.1.8 Core.
Here is a JIRA issue HHH-7821: https://hibernate.onjira.com/browse/HHH-7821.
It appears that the bug reporter began seeing it sporadically after upgrading from 4.1.6 to 4.1.8. The reporter mentioned that it is an involved application, and is trying to get an isolated recreatable scenario.
I don't know if this is the same scenario as yours (as all you posted was a Stacktrace), but you may wish to look at that (and other referenced JIRA HHH-7829) and if it is related, comment/monitor progress on those open JIRA Issues.
I just upgraded to Spring 3, and attempted to run some JUnits to make sure everything was copacetic. It wasn't. I got a SAXParseException when loading the context... it complained:
Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans-2.0.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .
My suspicion is that it couldn't access the XSD due to proxy configuration. Is there a way to make it stop trying so hard to validate it and just run the darn thing? :)
In all seriousness, though, I didn't have a problem when I was running under Spring 2, so I suspect that Spring 2 didn't bother to try to validate, but Spring 3 does. I was hoping there was a way to bypass that functionality.
One further clue... Since I couldn't run the JUnits, I went ahead and fired up the server (this is a web app), and everything seemed to go swimmingly. So that makes me think that Spring is just fine with my context files as they are.
Edit The same error occurs when using instead the Spring 3.0 schemas
It could be because you are using xsd of spring 2. You could try using http://www.springframework.org/schema/beans/spring-beans-3.0.xsd.
As it turns out, my problem was a result of re-bundling the spring jars into a single jar. Just using the separate jars worked fine for me.
I've got a website build with Spring and jpa (by hibernate). I've got a bug and I don't know how to identify the line where the bug appears.
I can't debug it on my ide because it's a live version (all runs fine in local).
I've got log which says:
o
rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011
at com.mycompany.server.rpc.UserService$$EnhancerByCGLIB$$64ed2d4f.createAccount(<generated>)#012#011
at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)
My problem is the third line. As the UserService object is handled by Spring, it becomes a proxy and I can't know the line of the bug.
Do you know how to solve the problem ?
Thanks
Is it possible for you to change from cglib to jdk proxy? (Spring AOP proxy reference)
Basically: if you access your beans as interfaces, you can use jdk proxies (spring default mechanism), thereby leaving the underlying object intact and gaining access to line numbers in stack traces.
I would say that not being able to reproduce this locally is a significant restraint. I would try to set up your local environment or a test server to reproduce the problem, using JMeter or other load test software to simulate load of concurrent user accesses. Once this is done, your tweak/compile/test cycle becomes a lot shorter, and you can make experimental changes without fear of disrupting service on your production server. It may seem like a lot of effort, but the work will pay dividends not just for this bug, but for bugs you may encounter in future.
It sounds like it could be a threading bug, especially since spring by default uses singleton scope. With that in mind, look into creating multithreaded integration tests for the service that is failing. Once you have reproduced the bug through load testing, you can verify that it's a threading bug by making your main service method synchronized, preventing concurrent use. If the bug disappears, it is most likely a concurrency bug.
As to finding the line of the bug - there is no line to look for since the code is generated. The best you can do is to add defensive checks in all beans that are being used in the advice around the UserService. (E.g. check for null values due to missing injections.) The init-method attribute on beans is useful for performing checks that the bean has been fully constructed and all required collaborators have been set.
If you cannot reproduce the issue in local environment, then may be it is environment / network related issue. I would first recreate the issue in test environment ( which is closer to production environment and not just own local machine ) to debug the bug.
You may also use Fiddler to debug network related issues for a live version.