Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Version: 3.4.2 I used "declare parents" for HttpSession and added a field. However, if use something that implements HttpSession, it does not get woven correctly if the mock class and the interface are not in the test cases. I blogged about what the original idea is here: http://www.beernut.ca/jim/archives/005157.html I think that it is a classloading issue, and I've asked on the mailing list. Opening a ticket on Andy Clement's request. http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg11472.html Reproducible: Always
Created attachment 153112 [details] a couple of projects to demo the problem attaching the "aspect" project and the "target" project that will demo the problem. In the target project there is a test case with some commented out code. Uncomment it to show the code working (it's my work around) or have the code not there to show the abstract method error.
Awesome work on that test case! I've recreated the problem. Not a clue what is wrong yet, but the testcase is a massive help!
Actually... as soon as I looked at the test aspect I had a suspicion. There is a long standing problem in AspectJ with LTW when using call with declare parents. If the call location is hit before the target of the declare parents has been woven then the pointcut may not match because when we look at the HttpSession it doesn't look like a ClusterableHttpSession. (I still need to work out why that manifests eventually as an AbstractMethodError) However, in order to work around this problem, the option completeBinaryTypes was created a long time ago. What this does is when the analysis of the call join point is being done and we pull in a type to look at it, if completeBinaryTypes==true then we will simulate the weaving of it (the weaving that will really be done later when the classloader actively loads HttpSession). By default when weaving class X and needing to load other types to check them, we don't do this because it isn't cheap. So your testcase will also pass if you change the aop.xml to this: <weaver options="-verbose -showWeaveInfo -Xset:weaveJavaxPackages=true,completeBinaryTypes=true"> In your testcase you observe you can uncomment a block in order to get it to pass, actually you just need to uncomment: private static void checkSession(HttpSession session) { } you don't need to call it or anything. Because HttpSession is specified there as a parameter type, it causes HttpSession to be loaded (and thus woven) when the test class is loaded. We can confirm this by leaving it uncommented and changing it to: private static void checkSession(String session) { } If we do that, the testcase fails again because the test type contains no reference to HttpSession. I'd normally say switch from call to execution if you can - as that shouldn't exhibit the same problem (because the execution join point occurs in the type you are affecting with the declare parents) - but I just tried it and it doesn't fix your case. Still get the AbstractMethodError. More thinking required...
completeBinaryTypes is the recommended way to deal with this (or switch from call to execution when LTW). completeBinaryTypes isn't cheap so the option is not default. Due to workaround I'm reducing the priority of this. An automatic way of knowing if completeBinaryTypes was necessary would be nice.
