Spring groovy中调用方法和

函数service.defects和service.getDefects（）的调用在groovy中有什么区别

---

在Groovy类中，属性访问

service.defects

成为对

service.getProperty（“缺陷”）

的调用，其默认实现最终将委托给

service.getDefects（）

。因此，从底部处理堆栈跟踪，

IncidentController

调用

getProperty（“事件”）

对象上的

service

对象，它是一个Spring AOP代理

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)

该方法没有标记为事务性的，因此Spring在对底层对象调用该方法之前不需要设置事务上下文

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)

现在，

ImportLogsService

的

getProperty

实现执行通常的默认行为，并调用自己的

getEvents

方法

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)

请注意，这是目标服务对象的内部，因此不再经过Spring事务代理层。因此，即使

getEvents（）

标记为

@Transactional

，也不会调用事务拦截器。最后，

getEvents（）

调用DAO层

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)

因为没有设置上下文，所以失败

如果首先调用

service.getIncents（）

，那么该方法（标记为transactional）将是Spring代理的第一个入口点，并且事务上下文将被正确设置

---

尝试将整个

ImportLogsService

类注释为

@Transactional

，而不仅仅是单个方法。这将导致事务拦截器在Groovy类中的属性访问上触发

getProperty

，以及

getEvents（）

service.defects

成为对

service.getProperty（“缺陷”）

的调用，其默认实现最终将委托给

service.getDefects（）

。因此，从底部处理堆栈跟踪，

IncidentController

调用

getProperty（“事件”）

对象上的

service

对象，它是一个Spring AOP代理

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)

该方法没有标记为事务性的，因此Spring在对底层对象调用该方法之前不需要设置事务上下文

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)

现在，

ImportLogsService

的

getProperty

实现执行通常的默认行为，并调用自己的

getEvents

方法

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)

请注意，这是目标服务对象的内部，因此不再经过Spring事务代理层。因此，即使

getEvents（）

标记为

@Transactional

，也不会调用事务拦截器。最后，

getEvents（）

调用DAO层

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)

因为没有设置上下文，所以失败

如果首先调用

service.getIncents（）

，那么该方法（标记为transactional）将是Spring代理的第一个入口点，并且事务上下文将被正确设置

---

尝试将整个

ImportLogsService

类注释为

@Transactional

，而不仅仅是单个方法。这将导致事务拦截器在

getProperty

以及

getincents（）

上启动

服务的类型是什么？在Groovy中，
foo.bar
通常意味着与
foo.getBar（）
相同，但某些类修改了该行为（例如，在
Map
上，调用
theMap.class
意味着
theMap.get（'class'）
而不是
theMap.getClass（）
）。服务是一个具有方法getDefects（）的自定义类它只是委托给DAO，而DAO又从DB中获取缺陷。应用程序在Spring上下文中运行，因此可能是Spring在代理对象时修改了行为吗？如果
服务本身是用Groovy编写的，那么是的，这是很有可能的。可能是（我在这里推测）Groovy
service.defects
变成了对类似
service.getProperty（'defects'）
的调用，后者最终调用
service.getDefects（）
，但是如果Spring在
getProperty
级别而不是
getDefects
级别介入并代理，那么您可能会看到不同的行为。错误的完整堆栈跟踪应该会让您有更多的了解。如果
service
实现了一个用Java编写的接口，并且您使用了接口代理（proxy target class=“false”）而不是CGLIB，那么您可能能够更精细地处理它。@IanRoberts我猜
service.getProperty（'defects'））
如果未显式编写属性，则实际上会在类中查找属性
getDefects（）
。在这种情况下，OP已经定制了访问器方法，因此我猜他必须在
getProperty
内部调用
getDefects
以使
服务.缺陷
起作用。
服务
的类型是什么？在Groovy中，
foo.bar
通常意味着与
foo.getBar（）
相同，但某些类修改了该行为（例如，在
Map
上，调用
theMap.class
意味着
theMap.get（'class'）
而不是
theMap.getClass（）
）。服务是一个具有方法getDefects（）的自定义类它只是委托给DAO，而DAO又从DB中获取缺陷。应用程序在Spring上下文中运行，因此可能是Spring在代理对象时修改了行为吗？如果
服务本身是用Groovy编写的，那么是的，这是很有可能的。可能（我在这里推测）Groovy
service.defects
变成了对类似
service.getProperty（'defects'）
的调用，后者最终会调用
service.getDefects（）
，但是如果Spring介入并在
getProperty
级别代理，而不是
getDef