tomcat下调试外部库，不修改它们
我们有一个网络应用程序，有时（非常罕见，一天几次）会给出 生产中的错误。部署在Tomcat上，使用Spring+Hibernate，导致错误 通过 Hibernate 异常，如果不实际记录就很难理解 传递给 Hibernate 类的方法的参数。无法更换 具有记录参数的修改版本的 Hibernate 库和 spring-aop 无法使用，因为“bean”不受管理。我看过字节码的例子 使用 javassist 进行检测，位于 http://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html,然而试图在下面运行它 tomcat，检测的代码似乎无法运行，可能是由于类加载器问题 我目前不明白。
那么我要问的是：有谁知道一种或多或少简单的仪器方法 tomcat 下的字节码，用于记录方法参数等任务 外部库？您对这个问题有什么进一步的见解吗？
We have a web application which sometimes (quite rarely, several times a day) gives an
error in production. It is deployed on Tomcat, uses Spring+Hibernate, the error is caused
by a Hibernate exception which is hard to understand without actually logging the
parameters passed to the method of the Hibernate class. It is not possible to replace
the Hibernate library with a modified version which logs the parameters, and spring-aop
cannot be used since the "beans" are not managed. I have seen an example of byte code
instrumentation using javassist, on http://today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html, however trying to run it under
tomcat, the instrumented code does not seem to run, probably due to classloader problems
which I currently don't understand.
What I am asking then, is this: does anyone know of a more or less simple way to instrument
the byte code under tomcat for such a task as logging the parameters of methods in
external libraries? is there some further insight you may give on this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看看 BTrace。
它将允许您记录对其他类/函数的调用，而不会减慢主应用程序的速度。
Have a look at BTrace.
It will allow you to log calls to other classes/functions without slowing down the main application.
您可以（暂时）在生产 Tomcat 上启用 JDWP，附加调试器，并在有问题的代码上放置断点。但我建议避免在实际的生产计算机上执行此操作 - 最好将生产环境克隆到另一台可以修改的计算机。
You could (temporarily) enable JDWP on the production Tomcat, attach a debugger, and place a breakpoint on the offending code. But I'd recommend avoiding doing that on the actual production machine -- better to clone the production environment to another machine that you can tinker with.