> there is actually an old byte code enhancer that is already manipulating the > classes in question that I am then asking for AspectJ to reweave with LTW
That is likely the cause. It is doing something a bit off with the class file leaving it in not quite an ideal state (e.g. a local variable reference that starts in the middle of an instruction rather than on an instruction boundary). You should be able to see things like that yourself - look at the class pre/post your extra byte code enhancer (javap -private -verbose), look at the method aspectj was struggling with - check the local variable table, exception tables, are they fully correct (i.e. pointing at instruction boundaries). Because eclipse JDT always supports older Java source/targets, 1.9 will work fine with Java8. AspectJ 1.9.2 will work with up to Java 11 - the JDKs are coming out so fast I am no longer doing matching AspectJ versions each time. I can’t guarantee you won’t hit anything but 1.9.2 passes all the same tests 1.8.13 did, with some extra tests on top of that too. Cheers, Andy > On Nov 19, 2018, at 2:16 PM, Eric B <ebenza...@gmail.com> wrote: > > Hi Andy, > > I can see if I can get a small test case working. Do you need source code > for all files, or is byte code good enough? The reason I ask is because > there is actually an old byte code enhancer that is already manipulating the > classes in question that I am then asking for AspectJ to reweave with LTW. > If I can reproduce, I have no issues with including the source code, but the > build process is a little convoluted and uses a custom maven plugin with some > custom libraries to do the byte enhancement. While anything is possible, > just makes getting the package ready more difficult. If just the .class > files are sufficient then it should be hopefully faster to produce. > > As for the 1.9.3, any thoughts on when this might be available in a release? > Are there any concerns I should have upgrading 1.8 to 1.9? I typically > always try to use the same version as the JDK (ie: use 1.8 for Java8 code, > 1.9 for Java 9 code, etc). Can I use 1.9 with a Java 8 compiler on a J8 > platform without any issues/worries? > > Thanks, > > Eric > > > > On Mon, Nov 19, 2018 at 12:18 PM Andrew Clement <andrew.clem...@gmail.com > <mailto:andrew.clem...@gmail.com>> wrote: > Hey, > > Obviously my preference would be to fix the problem, but that does require me > to recreate it. Not sure if you are able to share the project that leads to > it? (Or a cut down sample). It looks like something where I’d need to dig > into the byte code involved. > > In the interim I have added is(AbstractType) to go with all the others, just > fixed it under: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=541325 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=541325> > > I can give you a dev build with that in if that would be useful, I wasn’t > planning on an imminent 1.9.3 (this would be fixed in 1.9 line, not the 1.8 > line) > > cheers, > Andy > >> On Nov 16, 2018, at 8:19 AM, Eric B <ebenza...@gmail.com >> <mailto:ebenza...@gmail.com>> wrote: >> >> Thanks for the info; I suspected as much as not being able to target >> abstract classes directly (I hadn't found any documentation to that effect). >> >> Can you think of any other way I can attempt to exclude my problematic >> abstract classes without listing the explicitly? I'm hoping that something >> like the following might work: >> >> @Pointcut( "execution( * *..AbstractClass1(..)) || execution (* >> *..AbstractClass2(..)) || ... )") >> public void abstractClasses(); >> >> ** >> * Execution of any pcClearFields() methods within a newInstance as injected >> by Kodo Enhancer >> */ >> @Pointcut("cflow(!abstractClasses() && execution(* >> org.apache.openjpa.enhance.PersistenceCapable+.pcNewInstance(..))) && >> execution(* >> org.apache.openjpa.enhance.PersistenceCapable+.pcClearFields(..))") >> public void kodoNewObject(){} >> >> >> But I haven't tested it, and it's kind of ugly, so hoping I can find >> something a little less bad? >> >> Thanks, >> >> Eric >> >> On Fri, Nov 16, 2018 at 5:15 AM Alexander Kriegisch >> <alexan...@kriegisch.name <mailto:alexan...@kriegisch.name>> wrote: >> Sorry for being too busy to really investigate this report, but as a side >> note to Andy I want to mention that currently there is not way to express >> something like >> >> !within(* && is(AbstractType)) >> >> Since 1.6.9 [1] we have >> -- ClassType, >> -- AspectType, >> -- InterfaceType, >> -- InnerType, >> -- AnonymousType, >> -- EnumType. >> >> Since 1.8.4 [2] we have >> -- FinalType. >> >> According to [3] this still seems to be the current status. Maybe Andy wants >> to think about adding support for 'AbstractType', independently of how >> Eric's issue here is to be resolved. >> >> [1] https://www.eclipse.org/aspectj/doc/released/README-169.html >> <https://www.eclipse.org/aspectj/doc/released/README-169.html> >> [2] https://www.eclipse.org/aspectj/doc/released/README-184.html >> <https://www.eclipse.org/aspectj/doc/released/README-184.html> >> [3] >> http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/TypeCategoryTypePattern.java#n35 >> >> <http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/TypeCategoryTypePattern.java#n35> >> >> >> -- >> Alexander Kriegisch >> https://scrum-master.de <https://scrum-master.de/> >> >> >> Eric B schrieb am 15.11.2018 21:11: >> > >> > >> > I'm using aspectj 1.8.13 LTW'ing with Wildfly 10. Generally speaking, >> > everything is working as expected. However, I have recently added in a new >> > Pointcut which is causing core dumps by the weaver: >> > >> > >> > 2018-11-15 14:56:30,033 SEVERE [org.aspectj.weaver.loadtime.Aj] >> > izone/adams/model/messaging/SMSMessageAbstract: >> > java.lang.IllegalStateException: Unexpected problem whilst preparing >> > bytecode for model.messaging.SMSMessa >> > >> > geAbstract.pcNewInstance(Lorg/apache/openjpa/enhance/StateManager;Ljava/lang/Object;Z)Lorg/apache/openjpa/enhance/PersistenceCapable; >> > >> > at org.aspectj.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:699) >> > >> > at org.aspectj.weaver.bcel.LazyMethodGen.getMethod(LazyMethodGen.java:498) >> > >> > at org.aspectj.weaver.bcel.LazyClassGen.writeBack(LazyClassGen.java:515) >> > >> > at >> > org.aspectj.weaver.bcel.LazyClassGen.getJavaClassBytesIncludingReweavable(LazyClassGen.java:697) >> > >> > at >> > org.aspectj.weaver.bcel.BcelWeaver.getClassFilesFor(BcelWeaver.java:1443) >> > >> > at org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1405) >> > >> > at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1183) >> > >> > at >> > org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:527) >> > >> > at >> > org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:363) >> > >> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:121) >> > >> > at >> > org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54) >> > >> > >> > ... >> > >> > ... >> > >> > >> > at >> > org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.jrGetDeclaredMethods(DeploymentReflectionIndex.java:46001) >> > >> > at >> > org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:80) >> > >> > at >> > org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66) >> > >> > at >> > org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57) >> > >> > at >> > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106) >> > >> > at >> > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:91) >> > >> > at >> > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76) >> > >> > at >> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) >> > >> > at >> > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) >> > >> > at >> > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) >> > >> > at >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> > >> > at >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> > >> > at java.lang.Thread.run(Thread.java:745) >> > >> > Caused by: java.lang.NullPointerException >> > >> > at >> > org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:892) >> > >> > at >> > org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:863) >> > >> > at >> > org.aspectj.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:981) >> > >> > at org.aspectj.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:697) >> > >> > >> > I've traced it down to my new cflow pointcut which targets a method in >> > classes implementating a specific interface, but the weaver throws the >> > exception if it tries to weave an abstract class implementing this >> > interface. >> > >> > >> > My pointcut: >> > >> > >> > /** >> > * Execution of any pcClearFields() methods within a newInstance as >> > injected by Kodo Enhancer >> > */ >> > @Pointcut("cflow(execution(* >> > org.apache.openjpa.enhance.PersistenceCapable+.pcNewInstance(..))) && >> > execution(* >> > org.apache.openjpa.enhance.PersistenceCapable+.pcClearFields(..))") >> > public void kodoNewObject(){} >> > >> > >> > The weaver fails whenever it encounters an abstract class implementing >> > PersistenceCabaple without the pcNewInstance() method. >> > >> > >> > I'm not sure how to handle this. There is no functional failure with the >> > LTW failing as a non-abstract class gets properly woven. However, my logs >> > get polluted everytime the weaver tries to weave a such class and >> > generates a new ajcore.<timestamp>.txt file everytime which will quickly >> > fill my directory. >> > >> > >> > AspectJ LTW is being used with LTW enabled (<weaver options="-Xlint:ignore >> > -Xset:overWeaving=true" >). >> > >> > >> > Given that I'm running the latest of the 1.8 branch, is there a way I can >> > simply tell me pointcut to not target abstract classes? Is this even >> > feasible? >> > >> > >> > Thanks, >> > >> > >> > Eric >> > >> > >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://www.eclipse.org/mailman/listinfo/aspectj-users >> <https://www.eclipse.org/mailman/listinfo/aspectj-users> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://www.eclipse.org/mailman/listinfo/aspectj-users >> <https://www.eclipse.org/mailman/listinfo/aspectj-users> > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org> > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users > <https://www.eclipse.org/mailman/listinfo/aspectj-users>_______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
