Community
Participate
Working Groups
When AJDT is set to dump join points as 'info' into the markers view, it does so without giving any ability to filter by anything other than project. This is despite there being detailed path information. I'm using this for auditing in the absence of being able to trust the cross refs. It would be really useful to be able to navigate to the join point from the info marker, and also to filter them as the markers view allows. Examples include: 1) "Extending interface set for type 'base.Base' (Base.java) to include 'facade.IWeaveSuccessMarker' (WeaveSuccessMarker.aj)" Here, 'Resource' is set only to the project, but should be Base.java, preferably, with line set to the line of the class definition. 2) Join point 'constructor-call(void javax.swing.JCheckBox.<init>())' in Type 'base.SomePanel' (SomePanel.java:32) advised by afterReturning advice from 'com.camcog.cat.db.ForceBasicUIForBase' (ForceBasicUIForBase.aj:119) Here, 'Resource' is set only to the project, when clearly it should be a reference to ForceBasicUIForBase.aj:119.
Those text strings in the info messages are weaveinfo messages, just as would be produced on the command line with -showWeaveInfo. The only way to get at the parts of the message in order to do better processing would be to register an alternative message handler with the compiler that acts on the individual elements before they are converted to a plain string.
I am not familiar with this view, but it seems that the AJDT markers are not being properly created with the Markers view in mind. All the information that you are asking for is around when the marker is created. It is probably just a matter of creating the markers in the right way. Do you have a failing project that you can attach?
Hi Andrew, You should find that any AJ project will show these symptoms. I don't have anything trivial to attach at the moment. What do you get if you switch the markers on when compiling AJDT itself. That'd be a good example considering you're weaving other plugins too.
Well, I see that the markers do appear in the marker view and the file names and locations seem to be correct. I don't see anything unexpected with any of the projects I am looking at. The markers are populated from the same information that populates the xref view. So, if you are seeing problems in one, then you will likely be seeing problems in the other. There are a couple of bugs open about this already. I don't know if this is what you are encountering. For example bug 268522. If you can send a small project, I will explore.
Created attachment 129014 [details] Example of no line/resource info This is with the 27Feb09 dev build (Version: 1.6.4.20090227131914 AspectJ version: 1.6.4.20090227125800) from the update site on a normal project. Eclipse is 3.4.2 (Build id: M20090211-1700) It took some messing to get the Infos in the Marker view too. They didn't just appear straight after the build when I switched on the option.
(In reply to comment #5) > Created an attachment (id=129014) [details] > Example of no line/resource info I am guessing that you have the option showWeaveInfo enabled. That is why you are seeing all those info messages with no path information. These messages are generated by the compiler and are meant for debugging purposes and are not connected with AJDT's crosscutting model. So, those messages make sense. What is strange is that you are not seeing any AJDT markers. I don't know if the markers are being created and then deleted, or not created at all. Can you open your event trace, do a full build. And then do an incremental build (a whitespace change), and paste the output here? I am specifically looking for lines like: 16:13:43 Timer event: 1ms: Delete markers: MarkersView2 (Finished deleting markers for MarkersView2) 16:13:43 Timer event: 6ms: Create markers: MarkersView2 (Finished creating markers for MarkersView2)
Created attachment 129018 [details] As requested in comment 6
Thanks for the event trace. I believe what is happening is that the handles for the model elements are not being generated properly. In order to translate between JDT element and AspectJ elements, there is a unique handle created that is supposed to be the same across the langauge boundaries. See the two dependent bugs for information on what the discrepencies are.
Thanks. Glad I wasn't going insane ;)
I've been having a look at AC's initial suggestion to register an alternative message handler with the compiler. A search for uses of org.aspectj.bridge.WeaveMessage seems to show that this isn't as simple as it sounds, as the ISourceLocation that we could provide in the message super class, has been lost by this point. The factoy methods just pass null: private WeaveMessage(String message, String affectedtypename, String aspectname) { super(message, IMessage.WEAVEINFO, null, null); this.affectedtypename = affectedtypename; this.aspectname = aspectname; } I think that the ISourceLocation that goes in that second null should be shadow.getSourceLocation(), as referenced in BcelWorld.java:186 (where, it's turned into a String). I wonder if there is a performance reason or any other why passing the ISourceLocation ref would be something someone would want to avoid...
no, no reason for not including it - just didn't need it with the initial design. Now i think about it, I vaguely recall an old bug/enhancement request somewhere to add it so that it is visible to people plugging in.
Ok. I'll sort out a proposed patch then. I have a sufficiently big project to test a privately built plugin on to see if there are any adverse effects.
Created attachment 129786 [details] Proof of principle Attached patch breaks a handful of LTW unit tests where the output is now not what the test expects. I haven't checked yet whether this is the output from a production MessageHandler or a test handler.
Okay. I've had a further look at this, and the test failures are due to the tests expecting not to see the output rendered for the source location. The discrepancy in the tests is due to MessageUtil.renderMessage(..) being used as for output to stderr, which is then compared with the result in the test case. If I change those test cases to insert the correct " at <sourceLocation.toString>", then this sorts the tests. i.e. weaveinfo Join point 'lock(void java.lang.Object.<lock>(java.lang.Object))' in Type 'BasicProgram1' (BasicProgram1.java:11) advised by before advice from 'LockAspect1' (LockAspect1.java:6) becomes: weaveinfo at \BasicProgram1.java:11::0 Join point 'lock(void java.lang.Object.<lock>(java.lang.Object))' in Type 'BasicProgram1' (BasicProgram1.java:11) advised by before advice from 'LockAspect1' (LockAspect1.java:6) This improves the situation for those using AJDT and others who implement a MessageHandler, but it's not pretty for LTW. The problem for me is that IMessage should not be getting a message with ISourceLocation built in, and no one should be depending on Message.toString(), which returns MessageUtil.renderMessage(). I think we should patch the text of the tests, and see if anyone bleats. Longer term, I don't IMessage should have getMessage() and getDetails() returns strings. Rendering the output to a string is a UI thing, and should also allow NLS support. That's an enhancement for another day.
P.S. Note the Windows \ at the beginning of the file path. That'll break on Linux, so I'll look at SourceLocation.toString() too. Grrr!
Created attachment 130623 [details] workspace patch I applied the patch - thanks! And this is an updated version of it. - I modified formatting for weave messages to not include the source location in the output, so no tests expecting particular output need changing. That location is kind of only there for tools processing these messages anyway. - I notice the source location is not set for every kind of weave message, that must be done if they are to be recorded against the correct resource and not just considered top level project markers. If some are done and some are not, then those that are not set will come and go depending on what is rebuilt (as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=270635#c7 ) Would be nice to have some tests that verify the sourcelocation is actually correctly set within the message object. Looks like an early 1.6.5 piece of work.
Yeah. There's something about this area that has me thinking that it's better early in a release cycle. There is something rather 'wrong' about the contract through the bridge module which I have some thoughts on I'd like to get feedback from those using it. You've done what I had as a todo, which is to go and replace the null params that got inserted when I refactored to add the extra parameter.
Move to the 2.0.2 release.
No longer slated for the next release.
