Community
Participate
Working Groups
I made a change to the aspect JdbcMonitor, adding a single statement: declare parents: Connection+ && !java..* implements TrackedConnection; this resulted in an false incremental compilation error, which building the project incrementally repeatedly wouldn't fix. It was fixed by doing a clean rebuild. In this case JmxManagement is making a declare parents call and adding an ITD to JdbcMonitor. Here are the messages from the incremental AJDT event trace: AJDT version: 1.4.2.200701190932 for Eclipse 3.2 AspectJ Compiler version: DEVELOPMENT usingVisualiser=true usingXref=true usingCUprovider=false doneAutoOpenXRefViewC:/devel/glassbox = true doneAutoOpenXRefViewI:/devel/glassbox = true doneAutoOpenXRefViewc:/devel/workspace = true ajde.version.at.previous.startup = @AJDEVERSION@ doneAutoOpenXRefViewC:/devel/glassboxAccius = true C:/devel/workspace = true org.aspectj.ajdt.core.compiler.weaver.XLazyThisJoinPoint = true org.aspectj.ajdt.core.compiler.weaver.XReweavable = true org.eclipse.ajdt.internal.ui.tracing.checked.filters = set: Compiler,Compiler / Progress messages,Compiler / Task list messages,Builder,Builder / Classpath ajdocCommand = C:\java\jdk1.5.0_06\lib\tools.jar doneAutoOpenXRefViewc:/devel/glassbox = true doneAutoOpenXRefViewC:/devel/workspace = true c:/devel/workspace = true org.eclipse.ajdt.ui.preferences.ajdtPrefConfigDone = true org.eclipse.ajdt.internal.ui.xref.checked.filters = set: org.aspectj.ajdt.core.compiler.list.UnmatchedSuperTypeInCall = ignore org.eclipse.ajdt.ui.preferences.prefRunForAjdtVersion = 1.2.0.20050413151050 org.aspectj.ajdt.core.compiler.weaver.XSerializableAspects = true doneAutoOpenXRefViewC:/devel/glassboxHead = true 8:08:02 PM =========================================================================================== 8:08:02 PM Build kind = INCREMENTALBUILD 8:08:02 PM Project=monitor, kind of build requested=Incremental AspectJ compilation 8:08:02 PM Classpath=C:\devel\glassboxAccius\monitor\bin;C:/java/jdk1.5.0_09/jre/lib/rt.jar;C:/java/jdk1.5.0_09/jre/lib/jsse.jar;C:/java/jdk1.5.0_09/jre/lib/jce.jar;C:/java/jdk1.5.0_09/jre/lib/charsets.jar;C:/java/jdk1.5.0_09/jre/lib/ext/dnsns.jar;C:/java/jdk1.5.0_09/jre/lib/ext/localedata.jar;C:/java/jdk1.5.0_09/jre/lib/ext/sunjce_provider.jar;C:/java/jdk1.5.0_09/jre/lib/ext/sunpkcs11.jar;C:/eclipse/3.2.1/plugins/org.aspectj.runtime_1.5.4.200701151324/aspectjrt.jar;C:/devel/glassboxAccius/lib/buildtime/jsp-api-2.0.jar;C:/devel/glassboxAccius/lib/testonly/ant-1.6.2.jar;C:/devel/glassboxAccius/lib/testonly/cglib-nodep-2.1.jar;C:/devel/glassboxAccius/lib/testonly/commons-digester.jar;C:/devel/glassboxAccius/lib/testonly/jmock-20050507-203802.jar;C:/devel/glassboxAccius/lib/testonly/jmock-cglib-20050507-203802.jar;C:/devel/glassboxAccius/monitor/lib/runtime/commons-collections.jar;C:/devel/glassboxAccius/lib/aspectj/lib/aspectjweaver.jar;C:/devel/glassboxAccius/lib/buildtime/struts-1.2.4.jar;C:/devel/glassboxAccius/webClient/web/WEB-INF/lib/backport-util-concurrent.jar;C:/devel/glassboxAccius/lib/buildtime/servlet-api-2.4.jar;C:/devel/glassboxAccius/webClient/web/WEB-INF/lib/dwr.jar;C:/devel/glassboxAccius/lib/testonly/spring-mock-1.2.1.jar;C:/devel/glassboxAccius/agent/lib/runtime/commons-logging-1.1.jar;C:/devel/glassboxAccius/lib/buildtime/junit.jar;C:/devel/glassboxAccius/lib/buildtime/bdb-je-3.1.0.jar;C:/devel/glassboxAccius/lib/buildtime/bdb-db.jar;C:/devel/glassboxAccius/lib/buildtime/bdb-dbxml.jar;C:/devel/glassboxAccius/lib/spring/spring.jar;C:/devel/glassboxAccius/lib/buildtime/tc.jar; 8:08:02 PM Preparing for build: planning to be an incremental build 8:08:02 PM Starting incremental compilation loop 1 of possibly 5 8:08:02 PM AJC: compiling source files 8:08:03 PM Timer event: 1151ms: Time to first compiled message 8:08:03 PM AJC: compiled: C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj 8:08:03 PM addSourcelineTask message=The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getTopic() file=C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj line=27 8:08:03 PM addSourcelineTask message=The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getManagementInterface() file=C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj line=27 8:08:03 PM addSourcelineTask message=The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getOperationName() file=C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj line=27 8:08:03 PM addSourcelineTask message=TODO : push to a stack file=C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj line=270 8:08:03 PM addSourcelineTask message=The method getResultSetParameters(ResultSet) from the type JdbcMonitor is never used locally file=C:\devel\glassboxAccius\monitor\src\glassbox\monitor\resource\JdbcMonitor.aj line=448 8:08:03 PM AJDE Callback: finish. Was full build: false 8:08:03 PM Timer event: 1201ms: Total time spent in AJDE 8:08:03 PM Timer event: 60ms: Create element map (4382 rels in project: monitor) 8:08:03 PM Types affected during build = 1 8:08:03 PM Timer event: 250ms: Add markers (742 markers) 8:08:04 PM Timer event: 1843ms: Total time spent in AJBuilder.build() 8:09:33 PM Removed problems and tasks for project monitor 8:09:33 PM Builder: Tidied output folder(s), deleted 372 .class files 8:09:33 PM ===========================================================================================
This seems to be recurring fairly regularly whenever I make a valid change to the file. What information might help to narrow down the problem? I only compile incrementally from inside Eclipse...
This is still a problem with the latest version of AJDT. Indeed I'm having a hard time even forcing the tool to compile things fully in the right order at all. You could check out the latest workspace of Glassbox for an example of how this isn't working. This is a major impediment to development for us.
It turned out that in upgrading from 3.2 to 3.3, that the project lost the aspectpath setting that was applying these ITDs.
so is this working for you now Ron? Do you think the loss of the aspectpath is an AJDT problem with moving eclipse levels?
This bug is still a major problem for us. I was able to get the workspace to compile by forcing full builds, but incremental compilation still isn't applying ITD's to my aspects. E.g., if I change JdbcMonitor in any way I get these errors: Severity and Description Path Resource Location Creation Time Id The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getManagementInterface() monitor/src/glassbox/monitor/resource JdbcMonitor.aj line 27 1193442072843 37140650 The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getOperationName() monitor/src/glassbox/monitor/resource JdbcMonitor.aj line 27 1193442072843 37140651 The type JdbcMonitor must implement the inherited abstract method JmxManagement.ManagedBean.getTopic() monitor/src/glassbox/monitor/resource JdbcMonitor.aj line 27 1193442072843 37140649 If I save the type again, it still doesn't fix the build, so I have to force a clean build to make the ITDs on the aspect take effect. Here's a subset of the structure in question: public aspect JmxManagement { public interface ManagedBean { Class getManagementInterface(); ... } } public aspect MonitorJmxManagement { public interface RequestMonitorMBean extends EagerlyRegisteredManagedBean, RequestMonitorManagementInterface {} declare parents: AbstractMonitor implements RequestMonitorMBean; public Class RequestMonitorMBean.getManagementInterface() { return RequestMonitorManagementInterface.class; } ... } public abstract class AbstractMonitorClass { ... } public abstract aspect AbstractMonitorControl extends AbstractMonitorClass { ... } public abstract aspect AbstractMonitor extends AbstractMonitorControl { ... } public aspect JdbcMonitor extends AbstractMonitor implements Bean { ... }
thanks for the testcode Ron. I can see the problem exactly, just having trouble coming up with a robust solution. During the second build, which should be incremental, we compile JdbcMonitor. To complete its type hierarchy we pull in the AbstractMonitor class and apply the declare parents: AbstractMonitor implements RequestMonitorMBean; but unfortunately we only apply it to the eclipse representation of the type rather than the bcel representation that is hanging around from the previous compile. later we then use the bcel type when working out whether to apply the default implementation of the offending method 'getManagementInterface' and it doesnt get put onto AbstractMonitor because we dont think it implements RequestMonitorBean. I initially wanted to keep the bcel type in line with the eclipse type and made the change to the bcel type at the same time as we change the eclipse type. This works in this case but some other tests fail because the 'temporary' change to the bcel type is not undone correctly during weaving. It should be undone so that it is done completely correctly by the weaver. The infrastructure already exists for repairing temporary changes to the bcel types but it seems to have problems if mixed up with ITDs on interfaces where the default implementation needs to go on the top most implementor.
fixes committed. As discussed in previous comment - I decided to correctly modify the bcel delegate at compile time alongside modifying the eclipse delegate. This is then undone prior to weaving. This revealed a few issues that we had, like applying ITDs to types that were definetly not available at weave time (for example: "declare parents: Thread+ implements Foo" would put Foo on the Thread type at compile time even though the weaver would never do that at weave time, instead putting it on subtypes of Thread that it encounters). It feels good to uncover this problem and tidy things up to a degree, I just hope it doesn't break anyone accidentally relying on a quirk in their real world project... All tests pass, key changes in AjLookupEnvironment and BcelWeaver
fix available in aj dev builds - will be picked up in AJDT at some point...
