5

I've got a website build with Spring and jpa (by hibernate). I've got a bug and I don't know how to identify the line where the bug appears.

I can't debug it on my ide because it's a live version (all runs fine in local).

I've got log which says: o

rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011

at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011

at com.mycompany.server.rpc.UserService$$EnhancerByCGLIB$$64ed2d4f.createAccount(<generated>)#012#011

at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)

My problem is the third line. As the UserService object is handled by Spring, it becomes a proxy and I can't know the line of the bug.

Do you know how to solve the problem ?

Thanks

Jerome Cance
  • 8,103
  • 12
  • 53
  • 106
  • I would like to know the answer as well, but what I usually do in such case is poor man debugging - insert bunch of logger calls into a method and see at which line it stops. – serg Apr 15 '10 at 21:52
  • yes it is what I do too. But as my product is live, it means, create logs, recompile, send it to server and see. Oh no, I forgot a log, re do all the stuff... Really bad... – Jerome Cance Apr 16 '10 at 08:28
  • Can you post the complete log and provide some more details for the bug ? – Michael Pralow May 06 '10 at 16:14
  • my problem is not really to solve this bug but to know how to find the line of a bug in a proxy. I don't think you need additional information about it, isn't it ? – Jerome Cance May 06 '10 at 18:16
  • Without the possibility to debug - i guess you are lost. But you could try to change the used aop:advisor or create an own to log the "before" status of the object (and or inline log statements inside the object class). – Michael Pralow May 07 '10 at 06:41

3 Answers3

3

Is it possible for you to change from cglib to jdk proxy? (Spring AOP proxy reference)

Basically: if you access your beans as interfaces, you can use jdk proxies (spring default mechanism), thereby leaving the underlying object intact and gaining access to line numbers in stack traces.

Sean Patrick Floyd
  • 292,901
  • 67
  • 465
  • 588
  • this seems to be a good solution but is there any kind of performance issue or problem with this different model ? – Jerome Cance Aug 18 '10 at 07:33
  • not that I know of. as I said: it's the standard way of doing things in spring, thousands (maybe millions) of servers use it. If you inject your services as interfaces, not classes, spring will automatically use jdk proxies. – Sean Patrick Floyd Aug 18 '10 at 07:52
0

I would say that not being able to reproduce this locally is a significant restraint. I would try to set up your local environment or a test server to reproduce the problem, using JMeter or other load test software to simulate load of concurrent user accesses. Once this is done, your tweak/compile/test cycle becomes a lot shorter, and you can make experimental changes without fear of disrupting service on your production server. It may seem like a lot of effort, but the work will pay dividends not just for this bug, but for bugs you may encounter in future.

It sounds like it could be a threading bug, especially since spring by default uses singleton scope. With that in mind, look into creating multithreaded integration tests for the service that is failing. Once you have reproduced the bug through load testing, you can verify that it's a threading bug by making your main service method synchronized, preventing concurrent use. If the bug disappears, it is most likely a concurrency bug.

As to finding the line of the bug - there is no line to look for since the code is generated. The best you can do is to add defensive checks in all beans that are being used in the advice around the UserService. (E.g. check for null values due to missing injections.) The init-method attribute on beans is useful for performing checks that the bean has been fully constructed and all required collaborators have been set.

mdma
  • 56,943
  • 12
  • 94
  • 128
0

If you cannot reproduce the issue in local environment, then may be it is environment / network related issue. I would first recreate the issue in test environment ( which is closer to production environment and not just own local machine ) to debug the bug.

You may also use Fiddler to debug network related issues for a live version.

Harsha Hulageri
  • 2,810
  • 1
  • 22
  • 23