how to get proper stack trace instead of reflection stack trace?

I have a big red5 project and it seems that at some point a function is being executed. I tried finding in my code how come this specific function is being executed at that point and I couldn't find it. I want to find out what's calling it.

I read through the answers in stackoverflow and I found the following to show stack trace information of current position.

    StackTraceElement[] elements = Thread.currentThread().getStackTrace();
    for (int i=0;i<elements.length;i++) {
        log.error(elements[i].toString());
    }

and I received the following output:

java.lang.Thread.getStackTrace(Thread.java:1479)
component.lobby.LobbyMysql.getChallenges(LobbyComponentMysql.java:76)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.apache.commons.beanutils.BeanMap.get(BeanMap.java:390)
org.red5.io.amf.Output.writeObject(Output.java:357)
org.red5.io.object.Serializer.writeObjectType(Serializer.java:300)
org.red5.io.object.Serializer.writeComplex(Serializer.java:140)
org.red5.io.object.Serializer.serialize(Serializer.java:86)
org.red5.io.amf.Output.writeObject(Output.java:357)
org.red5.io.object.Serializer.writeObjectType(Serializer.java:300)
org.red5.io.object.Serializer.writeComplex(Serializer.java:140)
org.red5.io.object.Serialize开发者_如何学Cr.serialize(Serializer.java:86)
...

I do get the name of the function that being executed but the top levels for some reason are reflection classes. is there a way to find out the actual method that is calling this specific function ?

I'm not to Java and reflections so please bear with me :)

thanks

Clearly, the "actual" code is using reflection, so that's what you're going to see in the stack trace.

If you can run the code in debug mode, use a breakpoint instead of printing a stack trace. When the breakpoint is hit, look at what's happening in the suspended thread's call stack, specifically around this level:

java.lang.reflect.Method.invoke(Method.java:597)