TC8.1粘贴Bug修正

1.问题再现
粘贴bug是TC8.1非常难解决的bug，目前西门子还没有把它该bug列入高优先级解决。

所以我们只能暂时用这个零时的方法来解决这个bug
为了再现这个问题，我们需要找一台运算速度比较快的机器（2个以上的CPU）。

我相信这样的机器在研发中心应该很容易找到。

做大批量数据的“粘贴”“剪切”“挂结构”“更改所有权”时，如果打开“更多”面板，系统就会报错并且死循环。

只能从任务栏强行结束才行。

2.起因分析
查看%USERPROFILE%\Teamcenter\RAC\...路径下的日志可以发现大致有两类错误。

由于我的笔记本比较慢，只能再现其中的“错误二”。

2.1.错误一
用关键字“sun.java2d.NullSurfaceData cannot be cast to sun.java2d.d3d.D3DSurfaceData”到google中查询，发现一条有价值的线索：
/bbs/dv_rss.asp?s=xhtml&boardid=17&id=37697&page=4
摘要如下：
问题解决了，在这里给大家一个提醒，千万要小心System.out.println这个命令，尽量少用！！！我把代码里所有的这个句子删掉，一切都正常了！不知道其他的IDE是不是这样，反正我的WTK2.5.2是这样。

打印的内容没有用new创建对象时<可能> 会出现这种情况。

例如：
Aclass a;
System.out.println(a); //出错
改为：
Aclass a ＝ new Aclass();
System.out.println(a); //正常
2.2.错误二
用关键字“javax.swing.BufferStrategyPaintManager.prepare”到google中查询，发现几条条有价值的线索：
/forums/thread235043.html
/reference/programming/features/javarender/default.asp
主要是讲Active rendering的事情。

总结上面一些资料，我可以得出一个大胆的推测，这个错误会与java swt 以及多线程有关系。

其中的BufferStrategy还可能和图像绘制相关。

3.解决方案
3.1.尝试一
既然错误一是由于调用print出现的，我可以先关掉TC的所有的Java调试来防止这个错误。

打开RC端的%tc_root%\portal\plugins\configuration_8000.1.0\TcLogger.properties文件。

把里面的所有调试等级都设为“FATAL”，题外话，看来Log4j还是非常好用的工具配置相当灵活呀。

重启后，无奈得发现日志是没了，错误依旧。

3.2.尝试二
3.2.1.与swing相关的配置
显示图像利用了BufferStrategy，那我关闭这个功能或者干脆把“等待”“粘贴”“剪切”等图标从系统中删除试试呢。

打开google搜索与swing相关的配置，发现可以通过修改系统property实现。

-Dswing.bufferPerWindow=false可以关闭缓存防止swing的内存漏洞
-Dsun.java2d.opengl=true可以使用opengl非d3d，这样错误一就有可能被避免掉
-Dsun.java2d.pmoffscreen=false关闭offscreen pixmap支持，防止渲染出错
-Dj3d.threadLimit=1可以只使用一个线程，防止出错的概率，但同时降低显示性能。

经过反复调试，发现j3d.threadLimit参数的确和出错概率有关，当线程多了，非常容易出错。

线程为1时我的笔记本很少出错了，但不能完全避免。

如果不设该变量，默认为cpu数量加一，所以机器越快越容易出错！
其他的变量似乎没有实际的影响。

3.2.2.首选项copyPasteChunkNumber
在阅读源码过程中，我发现copyPasteChunkNumber首选项保存了默认批量提交的个数。

默认情况下系统没有设置该值，默认下，这个值被代码赋予了100。

当我设定为1时，系统每单个对象就提交一次，所以系统动作非常慢，这样我的笔记本电脑上已经几乎不出错了。

但是换了个台机，马上S给我看。

设为1000时，我的机器上来就S，以后我就用这个值来测试。

3.3.尝试四
更改JDK的版本。

我更换了jdk1.6的若干update，最好换成u20都一直没有解决这个问题。

更换Eclipse差价pde、jdt等的版本到最新，也是无济于事。

可见这个bug和Eclipse 也没有多大关系，而是最底层的Java问题。

3.4.尝试三
3.4.1.代码编写
阅读完mands.paste下所有类的源代码，并没有太多收获。

因为我没有找到与显示图片相关的源代码。

所以我怀疑出问题的代码藏在PasteDialog的父类、抽象类中。

终于在阅读AbstractProcessDialog时，让我找到了一丝眉目，于是我大刀阔斧开始反编译源码还原AbstractProcessDialog类的原貌。

修改了若干反编译时遗留的错误后，正式反编译成功。

当我阅读到setRowStatus函数是终于发现了这个“Active rendering”的核心语句，注释掉下面这句后，编译Java代码。

然后到Eclipse工程中找到生成的源代码。

由于这个类有内之类，编译完后生成的class 名称比较怪异。

找到系统原始类，发现这些类的名字竟然惊人得一致。

接着我们需要生成jar文件替换系统的mon_8000.1.0.jar。

我们都知道jar实际就是使用zip算法压缩的，所以方便起见，我直接使用winrar压缩生成jar。

分两步走：
全选mon_8000.1.0目录下所有的文件和文件夹，用winrar
压缩成zip格式。

●把生成的zip文件后缀改为jar
最后替换系统%tc_root%\portal\plugins\目录下的原
mon_8000.1.0.jar
3.4.2.测试
这个抽象类被很多地方用到，我暂时发现了四处，下面分为四个测试来进行验证debug 效果。

由于注释的代码是动态滚屏，所以注释完后屏幕不会自动下滚。

在下面四个测试中我们可以留意一下。

●打开“更多”粘贴一千多对象
●打开“更多”剪切一千多对象
●打开“更多”对一千多对象更改所有权
●打开“更多”在PSE中粘贴一千多对象
4.总结
在java发展过程中，多多少少还是会遇到各种各样的bug。

这个bug看似Teamcenter 的界面错误，实际上确实java swt swing的问题。

所以西门子在提交bug时虽然很容易再现，但是开发部给的答复是设计到核心代码，只能保持这个样子。

现在很难去说是西门子的代码的问题，因为单看西门子的代码这样的写法是OK的，也不能说是Eclipse的问题，它的调用机制也是合理的。

最终的源头是Java1.6，在它引入了新的一些特征以后，也暴露出它的bug。

速度的优化和稳定性在这个时候变成了鱼和熊掌不
能兼得。