今天还是扫除和更替为主

做一个连接，再看看另一个链接，再看第三个，和第四个，第五个，以后就做好一句话，照抄，the Create,jchinamed，另一个blogchina,edu,否酷，歪酷，另一个也不错再加一个。几个简单的全都行了，但是直接拷贝下来的就不行。还是先做好一页，以后全是抄吧。Alexa的计数看来挺操蛋的，周日到周一明显我是试验性作弊，弄到了2000左右，但是稍后就停了下来，而计数却仍是在2000多，甚至还有上下浮动。可见它的即时性颇为不准。估计有一些平滑性措施之类。还有，我是对着dep作弊的，而这也没有在记录上显示出来。

在 添加上instance和serialz自管理方法后出错，检查下来，发现是由于同一个实体的不同时侯是可以使用不同的Class的；同时，它不 一定总是带有全部的字段(field)方法;因此尽管instance/serializ方法总是存在（继承），但字段不在，仍是留下log记录；因此需 要添加判断：只能是指定的类而不是超类作为读取对象时才进行这种对象的串行处理。
在实际围绕着formtag的测试中产生了缺乏回归性的结果：一开始是没有得到dform,然后围绕着formtag为何没有成功转向做工作，忽然间，一 切都消失了，变成了另一个错误：在初始化实例时没有找到entity. 另外看来把所有相同的文件不因用途不同而分开是对的。

中 午睡了一觉后精神觉得好得多了。不过在重新检查role/member管理时却失了方向，不知道原来是如何实现的，而且老一套似乎根本就不能运 转，那怕是在www服务器上。唯一的办法似乎只能是在下班后他们都不干时把dep的换成旧的对照着操作。在此前，先进行其他，但马上就又发现问题。

实 际上在把转向的域名前缀去掉后，就不时发现有会话丢失的情况。开始以为是密码打错之类，但现在很清楚：在使用非主域名及struts的 action后，按ActionMapping的重定向都造成了会话的丢失。原因是什么，这里仍然没有很明确的认识；估计和中间有一个"/"的过程，在失 去了app路径后会丢失会话，这是经过验证的。但解释并不充分。由于ActionMapping的处理并不是完全透明的，这样，也就失去了进一步解决的可 能。使用非主导的工具体系的缺点也就在这里。可以改写一个同样的tag，看看用Hanva.ActionTag是否会出现同样的情况，或者会有更准确的认 识。这样一来，改写的部分就进一步延展了。在写这个程序前先把entitytaglib和cmdlib分开，由于处理程序越来越集中到taglib中，这 样原来的分类就显得太庞杂了。

然后就改写了那个logonAction为LogonTag，但是在这个程序能够开始工作前，最 终却发现会话仍是丢失了。直到，在改写中使用R,L 而不是L时，才得到修正。看来，这是与是不是struts的无关；而是与非正常域名的改写规则有关系。由于目前没有在首页提供登录，所以没有迹象表明同样 作用到首页，但可能性是非常大的。要维持二级域名全程，看来只能使用R改写。但是进一步显示的结果非常可怕，就是在二级域名改写的情况下，几乎没一次刷 新，都是一个新的会话记录。……但随后这种情况又消失了，显得非常的不确定。这下子也没有办法再进一步了，因此会话显得太不可靠,没有重复性，也就没有什 么可研究的地方了。目前可以做的也就只是知道session可能会丢失，以后在碰到类似问题时可以先查一下。

晚上九 点多了；终于回来重新看那个旧的会员管理为什么可以工作。原因在于Opflow把type传了过去(在这里显得挺巧妙的)，这样，尽管form中没有 type，但仍可以令cgi接受type。而现在没有 opflow，就只能让form预备下type了。葛兵，96688-013901310204；

roleadmin.jsp 是最早的一个列表jsp，同时也是最复杂的一个；也是唯一的一个两重列表。简化了要求后，实际上也同时是验证几个处理标 签的正确性。看来，还是应该把几个共同页面归一。明天，仍然需要一定时间继续搞清洁。随着五一假期的到来，不可能期望其他人帮忙了，还是我自已去验证最主 要的功能吧。