Difference in groovy between calling a method - spring

Question

What is the difference under the hood in groovy between the calls of the function service.defects and service.getDefects()
#RequestMapping("/test1")
ModelAndView getTest1() {
ModelAndView mav = new ModelAndView()
mav.viewName = "test"
List<Defect> defects = service.defects
mav
}
#RequestMapping("/test2")
ModelAndView getTest2() {
ModelAndView mav = new ModelAndView()
mav.viewName = "test"
List<Defect> defects = service.getDefects()
mav
}
I was struggling with this problem for quite a while, and although I thought the calls where the same, they are not. In my scenario the call of service.defects caused a "org.hibernate.HibernateException: No Session found for current thread" exception (getDefects() is Transactional though).
Can anybody explain me what is going on under the hood when I call the method with "service.defects"
This is the stack trace I get:
org.hibernate.HibernateException: No Session found for current thread
at org.springframework.orm.hibernate4.SpringSessionContext.currentSession(SpringSessionContext.java:97)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:883)
at org.hibernate.SessionFactory$getCurrentSession.call(Unknown Source)
at com.test.dao.LogDBDao.getExceptionLogFileEntry(LogDBDao.groovy:35)
at com.test.dao.ILogDBDao$getExceptionLogFileEntry.call(Unknown Source)
at com.test.service.ImportLogsService.getIncidents(ImportLogsService.groovy:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1580)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3308)
at com.test.service.ImportLogsService.getProperty(ImportLogsService.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at com.test.service.$Proxy27.getProperty(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at com.test.controller.IncidentController.getIncidents(IncidentController.groovy:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Answer 1

In a Groovy class, a property access
service.defects
becomes a call to service.getProperty("defects"), the default implementation of which will ultimately delegate to service.getDefects(). So working up that stack trace from the bottom, IncidentController calls getProperty("incidents") on the service object, which is a Spring AOP proxy.
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at com.test.service.$Proxy27.getProperty(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227)
at com.test.controller.IncidentController.getIncidents(IncidentController.groovy:22)
That method is not marked as transactional, so Spring has no need to set up the transaction context before calling the method on the underlying object
at com.test.service.ImportLogsService.getProperty(ImportLogsService.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
Now the getProperty implementation of ImportLogsService does the usual default behaviour and calls its own getIncidents method
at com.test.service.ImportLogsService.getIncidents(ImportLogsService.groovy:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1580)
at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3308)
Note that this is internal to the target service object, so does not go through the Spring transactional proxy layer again. Thus, even if getIncidents() is marked as #Transactional the transaction interceptor is not called. Finally getIncidents() calls into the DAO layer
at org.springframework.orm.hibernate4.SpringSessionContext.currentSession(SpringSessionContext.java:97)
at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:883)
at org.hibernate.SessionFactory$getCurrentSession.call(Unknown Source)
at com.test.dao.LogDBDao.getExceptionLogFileEntry(LogDBDao.groovy:35)
at com.test.dao.ILogDBDao$getExceptionLogFileEntry.call(Unknown Source)
which fails because there's no context set up.
If you called service.getIncidents() in the first place then that method (which is marked transactional) would be the first point of entry into the Spring proxy, and the transaction context would be set up correctly.
Try annotating the whole ImportLogsService class as #Transactional, rather than just the individual methods. This should cause the transaction interceptors to fire on getProperty as well as getIncidents().