http://dsr-22.iteye.com/blog/1258831
在项目中经常遇见这样的问题：修改应用的配置文件web.xml后，无论重启应用还是重启WebSphere服务器，都不能重新加载web.xml，导致修改的内容无效。
这个问题困扰了我好久，即使删除了${was安装目录}\IBM\WebSphere\AppServer\profiles\AppSrv01\下的temp和wstemp两个缓存文件夹下的临时文件，重启后还是无效。几经折腾，后来终于找到了问题所在——还是由于was的缓存机制导致的。
找到${was安装目录}\AppServer\profiles\AppSrv01\config\cells\xxxNode01Cell\applications\${应用名}.ear\deployments\目录下，有一个与应用相同名称的缓存文件夹，删除或修改该文件夹的web.xml，重启was即可。
在websphere中修改了jsp后，有时会出现修改的jsp没有起作用，特别是改变了某jsp的样式后，在页面中没看到效果，这主要就是由于websphere中缓存的缘故，这就要清除WebSphere中jsp缓存，如我的应用部署的目录为： E:\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\nbxzfwNode01Cell\项目名_war.ear\项目名.war 在这个目录下更新了某个jsp页面，后在浏览器里面查看的时候，发现页面没有改变。基于此，我查看了一下目录，存放应用临时文件的地方： E:\IBM\WebSphere\AppServer\profiles\AppSrv01\temp\nbxzfwNode01\server1\项目名_war\项目名.war 在这目录下，可以看到有很多class文件，都是jsp编译过来的，对应我们应用目录下的jsp文件，于是找到对应jsp的class文件删除，再到浏览器中查看，发现已经改变了。。 还有一种办法，就是把这个jsp从项目中删除或重命名，再到浏览器里面查看那个页面，这时可能会报错，之后，再把对应的jsp添加上或名字改过来，再次到浏览器里面查看应用的时候，就发现这jsp的更新效果出来了，呵呵…
前两天去客户那里给系统做升级，同时协助解决几个使用中的问题。到了现场第一件事情是把以前的应用导出做备份， 结果居然遇到返回null。查看日志发现系统报告空间不足，以前遇到这个问题是因为WAS出现oom(Out of Memory）之后，会生成javacore和dump文件供分析内存，这两个文件通常都比较大，30多M。如果多次出现oom，生成的文件就会占用大量空间。难道最近经常内存溢出？我心抽搐。 快马赶到Profile目录，没有发现导出文件，询问客户也没有出现系统宕机的情况，大石落地。仔细查看之后发现profile下的wstemp目录体积巨大，接近1.7G。这是个临时目录，每当管理员通过console登录之后，wstemp会生成一个新文件夹，保存管理员的所有操作记录，在管理员登出之后会删除该目录。但是wstemp下一堆的临时文件夹都没有被删掉，看来是was 5的bug又遗留到was 6了，真是搞不明白，was的这一堆补丁怎么都没解决掉这么明显的一个问题。N多RMB的was啊，越来越觉得还不如免费的jboss。 回公司之后查看了自己的was版本，wstemp目录2.4G，不过分区够大才没出问题。直接删之了事