Hi, An update on this:
I have fixed this for a specific scenario., i.e., in a specific scenario where the class/method and object variables are local variables and I have modified my code where I need a reflection continue to have the variables as local variables. For now, I had to do a few things I do not like, it is a hack. But I am able to get it to work consistently for any of the methods I have instrumented. Will come back and do a better job of it. In general I have followed the same guideline as I have outlined below.., except I had to do a few more things: 1) when the class is analyzed, I have fixed to recognize the variables that form the parameters for the java/lang/reflect/Method calls and store this as a part of the method 2) when the java/lang/reflect/Method is popped out I setup the parameters as the parameters I detected instead of null which is what is passed currently 3) I need to pop out the calling object reference also. 4) Currently I have only enabled this on the existence of an annotation ContinueReflection Attached the changes I have done. This also includes changes I had to do to port javaflow to asm 4.0_RC2, changes to consider different classloaders to resolve objects in the same stack trace. Thanx Rgds Raji .S. On Sun, Jul 1, 2012 at 10:59 PM, Torsten Curdt <tcu...@vafer.org> wrote: > Hey Raji, > > thanks for bringing this to the list > > I think the sketch in section 2.4 in > http://vafer.org/pub/papers/spasm.pdf gives a general overview of code > rewriting. > > As long as the method that is being called is instrumented properly > you should be able to make this work - with some changes necessary > though. Without looking into the current javaflow code I would think > that javaflow would need to also "record" reflection based calls to > methods (not just straight native method calls). So judging from your > code snippet you are on the right track there. Sorry, I can't be of > much more help at this time. > > You can do it! ;) > > cheers, > Torsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
