In Spring, why are line numbers lost for CGLib on a POJO?

Spring MVC web app:

I have a stack trace w/o line numbers (shown at bottom).

I presume that this is due to CGLib running on the controller. But this is odd to me, the actual exception occurs in ServerBatchRemoteRequestAcceptor, a pojo that is not injected, not the controller. It is only created in the Controller object.

Example:

@Controller
class MyController {
    MyPojo pojo = new MyPojo();

    @RequestMapping("myaction")
    public void doMyAction(){
        pojo.methodToCauseNullPointerException()
    }
}

java.lang.NullPointerException
at mycommons.services.batchremoteprocessor.ServerBatchRemoteRequestAcceptor.acceptRequest(Unknown Source)
at com.proxyandvpn.web.controllers.RESTServicesController.handleGenericClientRequest(Unknown Source)
at com.proxyandvpn.web.controllers.RESTServicesController$$FastClassByCGLIB$$dff24f0f.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodP开发者_运维技巧roxy.java:191)
at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:688)

Can someone explain this behavior to me? Will every call under my Controllers be without line numbers due to CGLib?

Should I write my Controllers to an interface so that proxies are used? Is that normal? I do it for services, but have done the controllers as simple POJOs.

Spring uses CGLIB to generate proxy objects that sit in front of some of your components/controllers. Calls to those components pass through the CGLIB proxies. These proxies are generated a runtime, with no source code, so they have no line numbers.

You can pretty much ignore the stack trace lines that mention CGLIB, though - pretend they're not there, they should be transparent.

In your stack trace, the call to RESTServicesController.handleGenericClientRequest has been proxied, but the call is still getting there. The NPE is occurring within ServerBatchRemoteRequestAcceptor, which is being invoked from RESTServicesController.handleGenericClientRequest.

However, the source code you posted has no relation to the stack trace, so it's hard to comment as to why it happened.

I will add to this answer as I now know my problem. As is common when you don't understand a problem, I didn't ask the right question.

I had recently switched to using ANT builds instead of Eclipse builder. I didn't realize that I needed to expressly enable debugging information in the task. I unwittingly blamed CGLib when I saw it sitting in front of this error, but all that was necessary was an ANT build modification.