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 <[email protected]> > 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
