[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ajdt-dev] AspectJ 1.6.4 bug on getParameterNames
|
I would open a bug for this or it will get lost on the list.
As you know, I don't particularly like users running with
XterminateAfterCompilation but let's not get into that debate again.
If you need to see the woven code from ltw, you can use the dump
option in aop.xml - that can dump out the code before and after
weaving, which can then be javap'd to spot any differences. If the
solution is just moving everything up to 1.6.4, that doesn't seem
unreasonable, I really haven't thought through the impact of
XterminateAfterCompilation with one level of AspectJ and then load
time weaving with another, but I wouldn't be surprised if that
scenario has issues.
cheers
Andy
2009/5/12 Simone Gianni <simoneg@xxxxxxxxxx>:
> Hi devs,
> the short version first :
> - Recompiling with 1.6.4 no problem, the problem happens with compiled 1.6.3
> then running with 1.6.4 rt LTW.
> - Tracing it down seems like BCEL is giving wrong data
> (LazyClassGen.initializeTjp receives from BCEL 1 parameter name and no
> parameter types)
> - BUT the javap of the same ITD aspect compiled with 1.6.4 (working) and
> 1.6.3 (not working) are identical.
>
> I'm a bit lost. I'll have continuum recompile and redeploy everything with
> 1.6.4 and the bug will go away, but IMHO it's worth investigating cause
> could happen again with next versions.
>
> Now the long version ...
>
> I was lucky enough to find the bug in the first 20 calls to factory.
>
> When Factory.makeMethodSig is called, these are parameters :
>
> modifiers "1" (id=42) methodName "handle_default" (id=3108)
> declaringType "org.apache.magma.website.RootWebHandler" (id=3093)
> paramTypes "" (id=49) paramNames "arg0:" (id=3110) exceptionTypes
> "" (id=49) returnType "org.apache.magma.website.WebHandler" (id=48)
>
> As you can see, there is a misterious "arg0" parameter, but no parameter
> type. The factory method is called by the <cinit> of the following, very
> simple, aspect :
>
> public aspect InstallWelcome {
>
> public WebHandler RootWebHandler.handle_default() {
> return new WelcomeWebHandler();
> }
> }
>
> The call is generated by 1.6.4 (cause LTW is running with 1.6.4), but the
> original aspect is compiled with 1.6.3 and with -XterminateAfterCompilation.
>
> (mostly useless) stack trace follows :
>
> Factory.makeMethodSig(String, String, String, String, String, String,
> String) line: 160 InstallWelcome.<clinit>() line: 22
> RootWebHandler.handle_default() line: 1
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
> available [native method] NativeMethodAccessorImpl.invoke(Object,
> Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[])
> line: 25 Method.invoke(Object, Object...) line: 597
> RootWebHandler(WebHandler).find(String[]) line: 132
> RootWebHandler(WebHandler).find(String) line: 112
> Dispatch.findProducer(String) line: 269
> Dispatch.handle(HttpServletRequest, HttpServletResponse) line: 99
> Dispatch.doGet(HttpServletRequest, HttpServletResponse) line: 63
> Dispatch(HttpServlet).service(HttpServletRequest, HttpServletResponse) line:
> 707 Dispatch(HttpServlet).service(ServletRequest, ServletResponse) line:
> 820 ServletHolder.handle(ServletRequest, ServletResponse) line: 502
> Now I'll try to dig a little inside the class generating these calls, which
> is LazyClassGen.initializeTjp .
>
> It turns out BCEL is giving false informations, since when we arrive to the
> method, the signature say :
>
> name "handle_default" (id=874) parameterAnnotationTypes null
> parameterNames String[1] (id=875) parameterTypes UnresolvedType[0]
> (id=876) paramSignature null reportedCantFindDeclaringType false
>
> As you can see, there is a spurious parameter name (for the curious : "arg0"
> :D ), but no parameterTypes, and strangely enough no paramSignature (usually
> it is "()" for all other methods I've seen).
>
> Since BCEL is obtaining this data parsing the aspect .class file, next step
> is a javap of the aspect ... 1.6.4 and 1.6.3 produced bytecode are
> identical. Since it is not weaved, there is no call to makeMethodSig to see
> what parameter are passed.
>
> So, I'm lost :D
>
> I don't know which modifications in BCEL can cause that behaviour, there has
> not been such a problem from AspectJ 1.6.2 to 1.6.3.
>
> Simone
>
>
>
>
>
> Simone Gianni wrote:
>>
>> Hi Andy,
>> I tried to reproduce it in a simple test case but yet no success.
>>
>> Just to give a bit more pointers :
>> - We're running in LTW, not tested if it happens in build time weaving
>> - Everything is compiled with 1.6.3, we were just running it with 1.6.4
>> LTW
>> - Classes and aspects are compiled using -XterminateAfterCompilation to
>> avoid LTW reweaving errors after other bytecode manipulators (like JPA or
>> Cobertura ones)
>> - The method on which the wrong parameter names are reported is called
>> using reflection (but the pointcut is execution(), so should not give
>> problems)
>> - The method on which the wrong parameter names are reported is an ITD
>> method
>> - It happens always, also on different machines, with 1.6.4, while with
>> 1.6.3 everything works always smoothly
>>
>> I tried to reproduce all this in a simple test program, with a method
>> having an argument calling (using reflection) a no-arg method and a ITD
>> no-arg method, compiling with 1.6.3 -XterminateAfterCompilation and running
>> it using the agent and the "aj" command, but still cannot reproduce the
>> problem.
>>
>> Tomorrow I'll try debugging Factory.makeMethodSig to see when it is called
>> with param names but no param types, unfortunately debugging in such a large
>> system will take up a lot of time, a small test case would have been m,uch
>> much better :(
>>
>> Simone
>>
>> Andy Clement wrote:
>>>
>>> No idea, please open a bug.
>>>
>>> Andy
>>>
>>> 2009/5/11 Simone Gianni <simoneg@xxxxxxxxxx>:
>>>
>>>>
>>>> Hi all,
>>>> since we have 1.6.4 in maven, we switched to it. Unfortunately however
>>>> it
>>>> seems like if there is a bug on 1.6.4 regarding getParameterNames on a
>>>> method signature.
>>>>
>>>> In fact, under 1.6.3, a method sigature with zero parameters returned a
>>>> zero
>>>> length array on both getParameterNames and getParameterTypes and a zero
>>>> length array on getArgs on the corresponding joinpoint instance. On
>>>> 1.6.4
>>>> getParameterNames returns an array of length 1 (in my case, containing
>>>> "arg0"), while all the others still return a zero length array.
>>>>
>>>> I suppose this is a bug, if none of you have a clear idea of why this
>>>> happens I can try build a simple testcase.
>>>>
>>>> Simone
>>>>
>>>> --
>>>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>>>> http://www.simonegianni.it/
>>>>
>>>> _______________________________________________
>>>> ajdt-dev mailing list
>>>> ajdt-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ajdt-dev mailing list
>>> ajdt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>>>
>>
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> ajdt-dev mailing list
> ajdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ajdt-dev
>
