很无语的，在更新了一个版本到Webtop后，发现Administration下的Presets不可用了，变成灰色 。实际上，使用原装的Webtop访问的时候，这个Presets还是可用的。
没有其他的办法，只好开始一步步的跟踪源代码，在PresetUtils这个类下面，发现可一个isPresetRepositoryAccessible函数，在进行Login登陆，以此生成的Session作为下一步工作的基础。其中登陆用户和密码是通过这种方式获取的：
IDfLoginInfo loginInfo = new DfLoginInfo();
loginInfo.setUser(presetContext.getPresetRepositoryUserName());
loginInfo.setPassword(presetContext.getPresetRepositoryUserPassword());
loginInfo.setDomain(presetContext.getPresetRepositoryUserDomain());
一时好奇，想看看这里通过Context获取到的究竟是什么东东，把对应的内容打印出来，结果令人大吃一惊，这里获取到的User和Password，不是我们登陆使用的Administrator的用户和密码，而是另外一个系统指定的默认用户：dmc_wdk_presets_owner，密码更是个默认值：webtop 不知道是从那里取到的，先拿来登陆了一把，不成功，想起之前曾经修改过这个用户的密码，造成了登陆失败。一步步调吧。
1、还原dmc_wdk_presets_owner用户的密码为 webtop；
2、重新使用刚才修改的用户名和密码登陆，登陆成功；
3、重新启动JavaMethods和Tomcat服务；
4、再次使用Administrator的账户登陆到Webtop。
OK。Presets可以正常看到并使用了。
这里还有一个地方需要注意，Presets在登陆的时候，读取的Docbase信息是来自于dfc.properties文件，所以需要保证我们的DFC配置文件中已经明确指明了对应的Docbroker信息。类似于下面的格式
dfc.docbroker.host[1]=192.168.1.XXX
dfc.docbroker.port[1]=1489
dfc.globalregistry.repository=XXX
dfc.globalregistry.username=XXXX
dfc.globalregistry.password=XXXXXX
几个小时的时间都在跟踪这个问题，缓存+无意义的密码修改+个人Tomcat中Properties文件的异同性，还有什么好说的。都凑一起了
不知道是否还有其他原因导致这个问题的存在。以后慢慢发掘......
posted on
