Community
Participate
Working Groups
QuestionGroupTreeViewScreen.java:29 error Ambiguous binding of type net.sf. hibernate.Session. Use one args(..) per matched join point import com.netvisor.common.data_model_metadata.EntityMetadata.Property; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ see attached file.
Created attachment 10592 [details] the file in question btw, i've encountered several aspectj compiler problems with importing/using inner types. this one is an inner interface of an interface. (EntityMetadata.Property)
Created attachment 10593 [details] the file that probably triggers it well, it's not a false error, but reported at the wrong place... the problem is here: Object around(Session connection): sessionableMethods() && ((args(connection, ..)) || (args(connection))) { this aspect is in a jar file on the classpath and it's concretized by an aspect while compiling. it open/closes hiebrnate connections automatically on demand. but how else can i do the above match if it will remain like this?
Thanks for trying out the new version so quickly. We'll look at the error message, but in the meantime you should be able to (re)write Object around(Session connection): sessionableMethods() && ((args(connection, ..)) || (args(connection))) { as simply: Object around(Session connection): sessionableMethods() && ((args(connection, ..)) { since '..' matches zero or more arguments
Message was introduced for bug 61568. The problem with the message is something that also occurs in bug 60015. We have the right line number but the wrong file.
"since '..' matches zero or more arguments" negative. first i tried like that with an old aspectj, and as saw it doesn't work i added the extra || (args(connection)). when the 1.2rc2 failed with the code i removed the extra args() and i end up with my old warning exception that the connection managed aspect doesn't work correctly.
sorry for speeding again, i double checked rc1 and rc2 and it DOES work ok. so, everything works fine except that the error message mentions the wrong file.
There is an unasserted rule in the message handling code (ours and the JDTs) that goes something like this: If you log an error whilst processing a resource, the primary sourcelocation must be in that resource and not in some other resource. If you violate this rule you get the bizarre source contexts that this bug highlights. It is a reasonable rule as when we log errors, we record them against the compilation result that the source location points to and when we have finished processing the resource we ask the infrastructure to 'accept' the compilation result and thats when the messages get put out. Suppose I am processing classes A and B, I finished processing A and there were no errors. I'm now processing B, during that processing I find a problem that is actually because of something in A. I cannot record my error against A because that has already been completely dealt with and anything I further record against it *wont get reported*. In this situation the first source location for the error should be the 'thing' in B that causes you to realise there was a problem in A, and then the extra source location should point to A. I have written some code to enforce this assertion and run the test harness - there were about 8 failures, and in every case there was a problem with the messages produced. Usually the text is OK but the indication of where to look for the problem is garbage.
Fix checked in. What I have done is: - For this particular case, I report two source locations - firstly which line the variable binding was being attempted upon and secondly which line the 2nd args(..) was encountered. This gives an error message like this: C:\Eclipse\212\eclipse\aspectj_ws2\tests\bugs\DisjunctVarBinding_2.java:25 error Ambiguous binding of type B using args(..) at this line. Use one args (..) per matched join point, see secondary source location for location of extraneous args(..) foo(b,a); ^^^^^^^^^^ see also: C:\Eclipse\212\eclipse\aspectj_ws2 \tests\bugs\DisjunctVarBinding_3.java:5 - To address the more general problem that we ought to 'assert', I have put some code into WeaverMessageHandler.handleMessage() that detects the situation of someone passing in the wrong primary source location and just avoids the processing that would lead to incorrect source context being reported (and so there is no problem with the error being logged against the wrong compilation result) I will move this bug to a enhancement request for post 1.2 to look at sorting out the error handling properly, putting the assert in and properly fixing the places that pass in unhelpful source locations. So, to sum up: With the fix in, you will get correct information, but with a little further work (too much to do before final) we can get you more information.
this bug seems to be with you from the commentary andy...
no updates for a while - I don't plan on doing more under this bug. I know we've done quite a bit to 'loosen' restrictions on binding, I imagine the new pointcut rewriter in 1.5 will allow Attilas original pointcut now...
