我们的产品中使用到这个特性了，主要是加载Jboss的AOP，另外Oneal的单元测试使用到了这个特性，使用的是jmockit，然后在Javaeye看到一个文章谈到性能优化，使用的是jamon，developerworks上也有两篇文章（ Java 5 特性 Instrumentation 实践和 Java SE 6 新特性: Instrumentation 新功能 ），需要好好关注下。
解惑
解己之惑，解人之惑
分类：Java (第7页共20页)
其实就是使用了JDK的JPDA，在启动服务器（Jboss或者Tomcat等）的命令行参数里面加上：
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
以Eclipse作为调试工具的话，创建一个Remote Java Application，连接参数填写正确的IP和端口（就是上面的8787）就行了
最近遇到的，偶然间解决的，如果一些文件和目录已经被Workspace中的一个工程引用（即使是处于Close状态的），如果你另外的工程创建到那些文件的引用的时候会报错，你刷新的时候也会出问题。最简单的解决办法就是关闭其他的工程，需要的时候再打开。
其实已经有很多文档了，不过还是老话，给自己备忘，总结些要注意的要点，给一些范例，以后肯定用得着。
以JK作为Apache和Tomcat的连接器，首先配置的是Apache的httpd.conf，主要是加载JK和配置转发规则：
加载和配置JK：
阅读全文
在写代码的时候我们可能会需要当前的方法名，特别是在输出一些调试信息的时候，但是如果使用字符串硬写的话不太好，API好像也不带对应的功能，如果细心的话，异常信息里面是带出错的方法名的，我们可以dump stack trace并分析得到当前方法的方法名，实际上有更好的方法，和dump stack trace类似：
public static String getCurrentMethodName() {
StackTraceElement element=Thread.currentThread().getStackTrace()[3];
return element.getClassName()+"."+element.getMethodName();
}
为什么是3呢？从0到2分别是：
java.lang.Thread.dumpThreads
java.lang.Thread.getStackTrace
xxx.Xxxx.getCurrentMethodName：也就是你定义这个工具方法的类
AOP绝对是个好东西，但是因为大部分的AOP实现都是通过修改字节码实现的，这就给Hot Deploy带来问题，在进行Hot Code Replace的时候JVM会抛错：Hot code replace failed – Hierarchy change not implemented，根据字面的意思，我猜测是JVM判断出原始的字节码有变化，但是JVM中的字节码是修改过的，类似子类的结构。目前还没有找到比较权威的解释，另外我对AOP也不是很熟悉，所以仅仅是猜测
也许有点老土了，但是这个插件确实是刚刚别人推荐给我的，而且很好用，特别是对于EJB开发之类的需要提供接口并实现的情况下，不用再自己去找实现类了。
感兴趣的自己去下载吧。
这个是最近的工作成果，使用JBossCache作为Hibernate的二级缓存，因为JBossCache支持Transactional的缓存策略(Strategy)，而且支持Cluster，Cluster还支持Invalidation的方式，比Replication方式更好，对两种方式同时支持同步和异步，还有其他很多特性，比OSCache好得多。
由于我们是把Hibernate作为服务配置的，所以CacheProviderClass使用的是org.jboss.hibernate.cache.DeployedTreeCacheProvider，需要另外一个MBean进行TreeCache的配置：
阅读全文
这个是进公司的第二个任务，由于是多个应用服务器集群，而产生pdf报表和发送邮件是通过JMS的异步方式，因此可能是服务器A产生PDF文件，而服务器B发送邮件，原来的实现是通过FileDataSource从本机取，因此有时候就不能成功发送邮件，后来修改为使用URLDataSource从自己写的一个Servlet取，但是很奇怪的是对于每个资源都会被请求三次，上网找了下，有个人也遇到同样的问题，但是他最后的解决方案不行，最后看了下URLDataSource的源代码（有兴趣的可以自己看看，注意getContentType和getInputStream的实现，每次都会开始一个新的请求），然后把URLDataSource重命名为自己的类试了下，发现getContentType方法会被调用两次，getInputStream方法被调用一次，对类稍稍做了修改，就是getContentType直接返回application/octet-stream类型，不真正请求服务器，问题解决，连带着昨天不能删除文件的问题也解决了，因为这样程序运行比较顺利，文件指针没有被占用，删除总是比较成功。
修改后的源代码：
阅读全文
Java的功能在某些地方确实很有缺陷，File的delete方法就是一个很大的问题，如果文件被使用而不能删除，那么这个方法调用是不会抛出异常的，也不会返回任何信息，就像方法调用根本没有发生一样。由于是临时产生的文件，如果不能删除，那么文件越来越多就可能撑爆硬盘。
方法当然可以有一些，例如可以加一个线程不停的试，，删除不成功就等待一段时间，直到删除成功，这个方法应该是比较有效的，因为大部分情况下，文件只是临时被占用，可能前后就差那么几百毫秒，当然，这个方法不完美，还是可能有漏网之鱼，明天再好好想想方法了。
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑