[
https://issues.apache.org/jira/browse/GROOVY-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605199#comment-17605199
]
Mauro Molinari edited comment on GROOVY-10757 at 9/15/22 10:35 AM:
-------------------------------------------------------------------
{quote}Can you say where BarPurchaseDao fits into the picture?
{quote}
That's exactly the point and the reason for which I can't figure out how to
workaround this. {{BarPurchaseDao}} does not fit at all in this picture. It's
just another extension of {{GenericServicePurchaseDao}} bound to another
{{{}BarPurchaseBean{}}}, which extends
{{GenericServicePurchaseBean<BarPurchaseDao>}} and hence receives a
{{BarPurchaseDao}} dao. But is has nothing to do with
{{{}FooPurchaseBean{}}}/{{{}FooPurchaseDao{}}}, it's in another branch of the
hierarchies of {{GenericServicePurchaseBean}} and
{{{}GenericServicePurchaseDao{}}}.
{quote}Not sure if Spring is getting tripped up by the covariant setDao methods
or what.
{quote}
If this were the case, the code wouldn't work in Groovy 2.5.15 either and it
wouldn't work when using Eclipse JDT/Greclipse. Spring in this case uses the
name to identify the right dao to inject into the setter, as you can see in
{{@Named('fooPurchaseDao')}} annotation, not its type.
{quote}There is a 2.5.19 snapshot available with many fixes. Can you give it a
quick try and say if this issue is still present?
{quote}
Is there any snapshot Maven repository where I can download this from? I'm
going to search for this.
Could the byte code of this class ({{{}FooPurchaseBean{}}}) produced by Eclipse
vs the one produced by groovyc (invoked by Gradle) be of any interest for you
to try to understand what could be the culprit? As I said, the first one works
fine, the second one fails at runtime.
Or else, the bytecode of this class produced by groovyc 2.5.15 vs 2.5.16 or
above...
I'm going to try your suggested workarounds, let me see if they change anything.
was (Author: mauromol):
{quote}Can you say where BarPurchaseDao fits into the picture?
{quote}
That's exactly the point and the reason for which I can't figure out how to
workaround this. {{BarPurchaseDao}} does not fit at all in this picture. It's
just another extension of {{GenericServicePurchaseDao}} bound to another
{{{}BarPurchaseBean{}}}, which extends
{{GenericServicePurchaseBean<BarPurchaseDao>}} and hence receives a
{{BarPurchaseDao}} dao. But is has nothing to do with
{{{}FooPurchaseBean{}}}/{{{}FooPurchaseDao{}}}, it's in another branch of the
hierarchies of {{GenericServicePurchaseBean}} and
{{{}GenericServicePurchaseDao{}}}.
{quote}Not sure if Spring is getting tripped up by the covariant setDao methods
or what.
{quote}
It this were the case, the code wouldn't work in Groovy 2.5.15 either and it
wouldn't work when using Eclipse JDT/Greclipse. Spring in this case uses the
name to identify the right dao to inject into the setter, as you can see in
{{@Named('fooPurchaseDao')}} annotation, not its type.
{quote}There is a 2.5.19 snapshot available with many fixes. Can you give it a
quick try and say if this issue is still present?
{quote}
Is there any snapshot Maven repository where I can download this from? I'm
going to search for this.
Could the byte code of this class ({{{}FooPurchaseBean{}}}) produced by Eclipse
vs the one produced by groovyc (invoked by Gradle) be of any interest for you
to try to understand what could be the culprit? As I said, the first one works
fine, the second one fails at runtime.
Or else, the bytecode of this class produced by groovyc 2.5.15 vs 2.5.16 or
above...
I'm going to try your suggested workarounds, let me see if they change anything.
> Regression from 2.5.16+: ClassCastException at runtime
> ------------------------------------------------------
>
> Key: GROOVY-10757
> URL: https://issues.apache.org/jira/browse/GROOVY-10757
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
> Affects Versions: 2.5.16, 2.5.17, 2.5.18
> Reporter: Mauro Molinari
> Assignee: Eric Milles
> Priority: Major
>
> I've found a very nasty bug in Groovy 2.5.16+.
> It's really hard to extract a simple test case, so I'll try to explain what
> is going on as much as possible.
> I have a {{@CompileStatic}} Groovy class hierarchy. Compilation succeeds, but
> a {{ClassCastException}} happens at runtime. The hierarchy is like this:
> {code:groovy}
> @Named
> @CompileStatic
> @Scope('session')
> abstract class GenericServicePurchaseBean<T extends
> GenericServicePurchaseDao> implements Serializable {
> T dao
> void setDao(final T dao) {
> this.dao = dao
> }
> protected abstract List<? extends ProductIdto> retrieveAvailableProducts()
> @CompileDynamic // see note below
> void resetState() {
> // ...
> retrieveAvailableProducts()
> // ...
> }
> }
> {code}
>
> {code:groovy}
> @Named
> @CompileStatic
> @Scope('session')
> class FooPurchaseBean extends GenericServicePurchaseBean<FooPurchaseDao> {
> @Inject
> @Named('fooPurchaseDao')
> @Override
> void setDao(final FooPurchaseDao dao) {
> super.setDao(dao)
> }
> @Override
> protected List<? extends ProductIdto> retrieveAvailableProducts() {
> dao.loadAllAvailableProductsForNewPurchase(customer)
> }
> @Override
> void resetState() {
> super.resetState();
> // ...
> }
> }
> {code}
> The error I get at runtime is this:
> {noformat}
> Caused by: java.lang.ClassCastException: class
> it.dcssrl.shop.web.purchase.view.dao.FooPurchaseDao$$EnhancerBySpringCGLIB$$271ceca2
> cannot be cast to class it.dcssrl.shop.web.purchase.view.dao.BarPurchaseDao
> (it.dcssrl.shop.web.purchase.view.dao.FooPurchaseDao$$EnhancerBySpringCGLIB$$271ceca2
> and it.dcssrl.shop.web.purchase.view.dao.BarPurchaseDao are in unnamed
> module of loader org.apache.catalina.loader.ParallelWebappClassLoader @5a075a)
> at
> it.dcssrl.shop.web.purchase.view.FooPurchaseBean.retrieveAvailableProducts(FooPurchaseBean.groovy:217)
> at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:234)
> at
> it.dcssrl.shop.web.purchase.view.GenericServicePurchaseBean.resetState(GenericServicePurchaseBean.groovy:682)
> at
> it.dcssrl.shop.web.purchase.view.FooPurchaseBean.resetState(FooPurchaseBean.groovy:148)
> [...]
> {noformat}
> If I remove the Groovy compiler optimization to enable Indy compilation, the
> error happens all the same, but the stack trace does not have the line about
> {{org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:234)}}.
> Please note that:
> - this problem does not happen with Groovy 2.5.15
> - it happens with Groovy 2.5.16, 2.5.17 and 2.5.18
> - it DOES NOT happen if compiling/running the application within Eclipse/WTP
> and Groovy Eclipse plugin
> - the {{resetState()}} method above in the base class is marked with
> {{@CompileDynamic}} because of another nasty problem I was not able to
> isolate, which otherwise produces another {{ClassCastException}} at runtime,
> although completely different from this one; this has been happening from
> 2.5.13 at least (it was not occurring with 2.5.9)
> Any idea of what is going on? And of a possible not-too-dirty workaround
> (apart from downgrading to Groovy 2.5.15)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
