Summary: | Incremental Compilation Fails on ITD of Aspect | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Ron Bodkin <rbodkin+LISTS> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | aclement, rbodkin+LISTS |
Version: | DEVELOPMENT | ||
Target Milestone: | 1.5.4 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Ron Bodkin
2007-02-09 23:17:28 EST
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... |