error can't determine superclass of missing type

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

error can't determine superclass of missing type

David Wright
I have an aspect with pointcuts like:
call(* java.util.concurrent.Executor+.execute(Runnable)) && args(r) && within(myapp..*)

Unfortunately, the application tests (run by surefire plugin in a maven build) also use Mockito for mocking.

I have code that looks like:
SomeInterface amock = Mockito.mock(SomeInterface.class)
Then, the class under test is instantiated as:
MyClass c = new MyClass(amock)
My test may invoke something like
c.doStuff(),
and c.doStuff() calls amock.otherStuff() (You could say we're running amock )

When running this test, I get a warning displayed:
error can't determine superclass of missing type myapp.somepackage.SomeInterface$MockitoMock$1883234141$auxiliary$Ke7g6xEG
when weaving type myapp.somepackage.SomeInterface$MockitoMock$1883234141
when weaving classes
when weaving

Using a bit of reflection, I found that the class hierarchy for the mock instance (the 'amock' above) looks like:
Class myapp.somepackage.SomeInterface$MockitoMock$1883234141
implements interfaces myapp.somepackage.SomeInterface and org.mockito.internal.creation.bytebuddy.MockAccess.
The superclass of myapp.somepackage.SomeInterface$MockitoMock$1883234141 is Object.

The warning message appears to reference an inner class of the mock class, and the weaver can't find this inner class??

So, I tried modifying the pointcut to
!cflow(call(* org.mockito.internal.creation.bytebuddy.MockAccess+.*(..))) && call(* java.util.concurrent.Executor+.execute(Runnable)) && args(r) && within(myapp..*)
in an attempt to exclude any joinpoints that occur within the scope of executing any method of the mock instance.

No effect - same warning appeared. Ideally, the pointcut that resolves this issue would not include cflow, for the sake of performance. I believe that cflow is handled by checking a value of a ThreadLocal, but I would still prefer to not have that overhead.

By the way, I'm using AspectJ 1.8.9, and have to use the @AspectJ syntax with load-time weaving, instead of using the ajc compiler. My aop.xml file looks like:
<aspectj>
    <aspects>
        <aspect name="myapp.TroubleAspect"/>
    </aspects>

    <weaver options="-XnoInline">
        <include within="myapp..*"/>
    </weaver>
</aspectj>

Note that the aspect works as it is supposed to. The purpose for the aspect is not related to invoking methods on mock objects. We anticipate making fairly extensive use of Mockito, though, and I would prefer to avoid the resultant flurry of warning messages.

Any ideas?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

Alexander Kriegisch-2
Hi David.

Would you mind providing a reproduceable example, e.g. a little GitHub project, complete with pom.xml etc.? A minimal example would also make it easier for the maintainers to create a regression test in case this proves to be a bug.

Thanks
--
Alexander Kriegisch
https://scrum-master.de

> Am 20.12.2016 um 06:56 schrieb David Wright <[hidden email]>:
>
> I have an aspect with pointcuts like:
> call(* java.util.concurrent.Executor+.execute(Runnable)) && args(r) &&
> within(myapp..*)
>
> Unfortunately, the application tests (run by surefire plugin in a maven
> build) also use  Mockito <http://site.mockito.org/>   for mocking.
>
> I have code that looks like:
> SomeInterface amock = Mockito.mock(SomeInterface.class)
> Then, the class under test is instantiated as:
> MyClass c = new MyClass(amock)
> My test may invoke something like
> c.doStuff(),
> and c.doStuff() calls amock.otherStuff() (You could say we're running amock
> )
>
> When running this test, I get a warning displayed:
> error can't determine superclass of missing type
> myapp.somepackage.SomeInterface$MockitoMock$1883234141$auxiliary$Ke7g6xEG
> when weaving type myapp.somepackage.SomeInterface$MockitoMock$1883234141
> when weaving classes
> when weaving
>
> Using a bit of reflection, I found that the class hierarchy for the mock
> instance (the 'amock' above) looks like:
> Class myapp.somepackage.SomeInterface$MockitoMock$1883234141
> implements interfaces myapp.somepackage.SomeInterface and
> org.mockito.internal.creation.bytebuddy.MockAccess.
> The superclass of myapp.somepackage.SomeInterface$MockitoMock$1883234141 is
> Object.
>
> The warning message appears to reference an inner class of the mock class,
> and the weaver can't find this inner class??
>
> So, I tried modifying the pointcut to
> !cflow(call(* org.mockito.internal.creation.bytebuddy.MockAccess+.*(..))) &&
> call(* java.util.concurrent.Executor+.execute(Runnable)) && args(r) &&
> within(myapp..*)
> in an attempt to exclude any joinpoints that occur within the scope of
> executing any method of the mock instance.
>
> No effect - same warning appeared. Ideally, the pointcut that resolves this
> issue would not include cflow, for the sake of performance. I believe that
> cflow is handled by checking a value of a ThreadLocal, but I would still
> prefer to not have that overhead.
>
> By the way, I'm using AspectJ 1.8.9, and have to use the @AspectJ syntax
> with load-time weaving, instead of using the ajc compiler. My aop.xml file
> looks like:
> <aspectj>
>    <aspects>
>        <aspect name="myapp.TroubleAspect"/>
>    </aspects>
>
>    <weaver options="-XnoInline">
>        <include within="myapp..*"/>
>    </weaver>
> </aspectj>
>
> *Note that the aspect works as it is supposed to*. The purpose for the
> aspect is not related to invoking methods on mock objects. We anticipate
> making fairly extensive use of Mockito, though, and I would prefer to avoid
> the resultant flurry of warning messages.
>
> Any ideas?
>
>
>
>
>
>
> --
> View this message in context: http://aspectj.2085585.n4.nabble.com/error-can-t-determine-superclass-of-missing-type-tp4652184.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> _______________________________________________
> aspectj-users mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright 3
Sample project has been created.

See  GitHub project
<https://github.com/DavidWright916/aspectj_superclass_issue>  


It occurred to me why my cflow attempt didn't resolve the issue. Cflow is
evaluated at runtime, while the weaving happens at class load time for the
mock instance.

Anyway, the warnings still appear in the sample project, so happy cloning!



--
View this message in context: http://aspectj.2085585.n4.nabble.com/error-can-t-determine-superclass-of-missing-type-tp4652184p4652186.html
Sent from the AspectJ - users mailing list archive at Nabble.com.
_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright
This post has NOT been accepted by the mailing list yet.
In reply to this post by Alexander Kriegisch-2
Sample project has been created.

See GitHub project


It occurred to me why my cflow attempt didn't resolve the issue. Cflow is evaluated at runtime, while the weaving happens at class load time for the mock instance.

Anyway, the warnings still appear in the sample project, so happy cloning!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright
This post has NOT been accepted by the mailing list yet.
As a side note of interest, I initially wanted an aspect that would advise construction of Runnable and Callable objects within the scope of our code.
I got this working, except it doesn't work when the Runnable or Callable is written using lambda expressions.
For example,
Runnable r = ()->{do stuff}
does not trigger construction, initialization, or preinitialization joinpoints.
I'm using Oracle java 1.8.0_111 on Ubuntu 16.10, kernel 4.8.0-32.
I've tried this with AspectJ 1.8.9 and 1.8.10.

-- 
David Wright
Developer
Innovapost
Phone 613-271-7770
Email [hidden email]

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

-----Original Message-----
From: David Wright [via AspectJ] <[hidden email]>
To: David Wright <[hidden email]>
Subject: Re: error can't determine superclass of missing type
Date: Tue, 20 Dec 2016 12:23:12 -0800

Sample project has been created.

See GitHub project


It occurred to me why my cflow attempt didn't resolve the issue. Cflow is evaluated at runtime, while the weaving happens at class load time for the mock instance.

Anyway, the warnings still appear in the sample project, so happy cloning!


If you reply to this email, your message will be added to the discussion below:
http://aspectj.2085585.n4.nabble.com/error-can-t-determine-superclass-of-missing-type-tp4652184p4652187.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

Andy Clement
In reply to this post by David Wright 3
I’m imagining it is because some AspectJ lookups involve accessing the bytes for types via getResource calls. If the class loaders involved can’t return those bytes, the types will be reported as not found. This could happen for a system where those bytes are rather transient (not on disk) and that is dynamically defining classes on the fly (mocks in this example). For these kinds of reason cantFindType is actually a configurable message. If you are confident your system is working even without these types being found then they weren’t needed to complete the analysis and you can turn the messages off. Something like -Xlint:ignore in aop.xml, but I’m afraid I can’t recall if we added individual message control (for cantFindType) from aop.xml or if you can use the -Xlintfile option from there.

cheers,
Andy

> On Dec 20, 2016, at 10:51 AM, David Wright <[hidden email]> wrote:
>
> Sample project has been created.
>
> See  GitHub project
> <https://github.com/DavidWright916/aspectj_superclass_issue>  
>
>
> It occurred to me why my cflow attempt didn't resolve the issue. Cflow is
> evaluated at runtime, while the weaving happens at class load time for the
> mock instance.
>
> Anyway, the warnings still appear in the sample project, so happy cloning!
>
>
>
> --
> View this message in context: http://aspectj.2085585.n4.nabble.com/error-can-t-determine-superclass-of-missing-type-tp4652184p4652186.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> _______________________________________________
> aspectj-users mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright 3
Thanks.

This fixed the issue:
Changed aop.xml to
<aspectj>
    <aspects>
        <aspect name="myapp.SampleAspect"/>
    </aspects>

    <weaver options="-XnoInline -Xlint:-cantFindType">
        <include within="myapp..*"/>
    </weaver>
</aspectj>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright 3
Actually, on second glance, something more odd has happened.

Although the warnings about not finding the class are missing, I get this warning:
error invalid Xlint message kind (must be one of ignore, warning, error): -cantFindType
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

David Wright 3
I ended up doing this:

Creating a file, say aspectjlint.properties
containing
cantFindType = ignore

Then, my aop.xml file was changed to:
<aspectj>
    <aspects>
        <aspect name="myapp.SampleAspect"/>
    </aspects>

    <weaver options="-XnoInline -Xlintfile:aspectjlint.properties">
        <include within="myapp..*"/>
    </weaver>
</aspectj>


This works with no additional warnings/errors.

I assume that the lintfile is additive, so that all of the other entries in XlintDefault.properties (in the weaver jar) still apply.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: error can't determine superclass of missing type

Andy Clement
Glad you got it working. The shorthand mode that doesn’t require the file is something like -Xlint:cantFindType=ignore but I haven’t tested it from LTW (it may only work as a command line flag).

>
> I assume that the lintfile is additive, so that all of the other entries in
> XlintDefault.properties (in the weaver jar) still apply.

I believe that is true.
cheers,
Andy

> On Dec 21, 2016, at 9:51 AM, David Wright 3 <[hidden email]> wrote:
>
> I ended up doing this:
>
> Creating a file, say aspectjlint.properties
> containing
> cantFindType = ignore
>
> Then, my aop.xml file was changed to:
> <aspectj>
>    <aspects>
>        <aspect name="myapp.SampleAspect"/>
>    </aspects>
>
>    <weaver options="-XnoInline -Xlintfile:aspectjlint.properties">
>        <include within="myapp..*"/>
>    </weaver>
> </aspectj>
>
>
> This works with no additional warnings/errors.
>
> I assume that the lintfile is additive, so that all of the other entries in
> XlintDefault.properties (in the weaver jar) still apply.
>
>
>
> --
> View this message in context: http://aspectj.2085585.n4.nabble.com/error-can-t-determine-superclass-of-missing-type-tp4652184p4652193.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> _______________________________________________
> aspectj-users mailing list
> [hidden email]
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Loading...