true --DataSouceName[optional,defaultto"default"],datasoucename（mustbethesameasDataSource'sGroupname）->
--configValuekey="DataSouceName">default
当EOS启动调试服务时，控制台停留在RCALL后无反应
一般是因为定时任务的表被锁住的原因，可在plsqldeveloper中执行以下语句：
select'altersystemkillsession'''||||','||#||'''immediate;'
fromv$locked_objectb,v$sessionc
where=
将查询结果复制到新的SQL窗口执行，执行完成后再启动服务
--解决EOS连接失败无法启动的问题--查看有没有被锁的对象
select*fromv$locked_object--查看被锁的对象是哪张表
select*fromdba_objectswhereobject_idin（selectfromv$locked_objectt）
--select*fromdba_objectswhereobject_id=73713--从菜单栏进入Tools/Sessions，将Status='ACTIVE'andSid=被锁对象id的记录，点击右键菜单中的Kill
跟操作系统的兼容性有关，建议去下看ide\eclipse\plugins目录下和两个jar的版本，更换成高版本试试。
提供清理eos开发过程中缓存清理的方法
摘要：
提供清理eos开发过程中缓存清理的方法。
在eos开发过程中，经常遇到新开发的代码无法使用，右键部署之后依然使用原来的老旧代码，非常影响开发速度。
这里提供下清理缓存的方式，确定我们的最新代码能够被使用。
对于分组开发过程中，各人代码版本差异无法实现同样的运行效果有特效。
1. 删除%EOS_HOME%\apps_config\default\work_temp下的所有文件和文件夹。
如需使用平台的各种日志请酌情备份logs下的内容。
2. 删除%EOS_HOME%\下的所有内容，情况tomcat的缓存。
3. 删除%EOS_HOME%\下我们自己项目的内容。
慎重，别删错了，我们自己开发的。
ESB修改默认端口61616
windows操作系统下的默认的ICS服务（InternetConnectionSharing）默认占用了61616端口，因此要解决jms端口冲突的情况有两种方式。
方式一：
停止ICS服务。
命令行执行“”,找到ICS服务，右键停止，并设置为以后手动启动。
方式二：
修改ESB下JMS默认端口。
找到D:
\Primeton\ESB\studio\server\EOS\_srv\config下的和文件，分别修改如下内容：
（
5
1
如何修改Platform发布Webservice服务的命名空间
摘要：
如何修改Platform发布Webservice服务的命名空间（）为自己指定的名字。
问题描述:
Platform发布Webservice服务，在浏览器上查看wsdl，客户想修改其中的命名空间，如下图红色框的内容，想更换成自己的命名空间。
适用环境:
PlatformV6及以上版本
处理经验:
可以修改中的配置，将DefultNameSpace这行的注释放开，修改为自己指定的值。
--
应用被拦截，调用报错无法访问
摘要：
应用被拦截，调用报错无法访问
场景描述：
放在 Tomcat 的 webapps/ROOT 目录下，或者其他非default应用下
该静态 HTML 页面中有一个超链接 EOStest
在资源管理器中直接双击该文件，在浏览器打开后（ 协议），点击该超链接可以正常访问。
但如果我通过 访问该页面（ 协议），点击该超链接时，直接报错了，错误信息为：
调用异常，请查看日志！
而使用没有问题。
EOStest，
functionopen_win（）
{
（""）
}
情况分析：
获取前后http头，referer为不同应用之间的请求，那么可能被default给拦截了。
解决办法：
去除拦截器：
把apps_config\default\config\eos\中的以下配置注释掉，看看是否还会不会有问题：
摘要：
EOS工程部署到JBOSS后报错。
分析日后初步确定为"\"与"\"冲突导致
该问题已经解决。
方案如下：
修改jboss\server\default\deployers\\META-INF\ 添加，以过滤该包
代码如下：
1.
-- Allow for war local class loaders:
in testing -->
2.
3. -1
4. ,
5.
然后重启JBOSS服务器。
原因分析：
jboss加载jar包顺序问题。
摘要：
在最近修改SSO应用的时候，涉及到需要在jar包中读取工程配置文件的问题。
在jar包中，读取配置文件，需要单独处理。
项目中的一些配置文件，如不想打包进jar。
因为可能会修改其中的一些配置信息，打包进jar，就变得比较笨拙，不方便修改文件。
可以用如下方式，实现在jar包中读取外部配置文件。
方法一：
关键代码。
读取properties文件方法：
InputStream ins = getClass（）.getResourceAsStream（"/resource/"）;
但是又需要单独处理：
（""） + "/resource/"）;
方法二：
配置文件和jiar包在同一个目录下面：
FileInputStream inputStream1 = new FileInputStream（""）;
配置文件在jar包内部：
InputStream inputStream2 = "/"）;
WSDoAllReceiver:
摘要：
使用自动生成的客户端代码，在调用带有安全头部消息的webservice接口的时候，会经常出现WSDoAllReceiver:
IncomingmessagedoesnotcontainrequiredSecurityheader的异常，可以照下文处理
使用自动生成的客户端代码，在调用带有安全头部消息的webservice接口的时候，会经常出现WSDoAllReceiver:
IncomingmessagedoesnotcontainrequiredSecurityheader的异常，表示传入的消息不包含所需的安全报头，经过分析发现是该方法在第一次被调用后，已经生成了一些安全校验数据，不为空，无法对新的请求进行安全数据的封装，导致请求失败，应该清空应用环境，重新生成对应的安全校验数据。
可以照如下方式进行处理。
在使用客户端代码的方法中，加入=null;
用于清空运行环境，以对新的请求，作出新的安全设置。
示例代码片段：
@Bizlet
publicMapsellOrderPriceUpdate（SellOrderImplsellOrderImpl,SellOrderDetailImpl[]sellOrderDetailImpls）throwsException{
=null; 户环境
产品版本：
EOSPlatform
服务器：
Was7，4个节点的集群
数据库：
Oracle11g
JDK版本：
浏览器：
IE7
二.问题描述
客户环境上主要表现为通过逻辑流调用了BPS的服务，同时在逻辑流里面存在业务数据的操作，调用完逻辑流之后，流程数据和业务数据都丢失了，且整个过程没有抛出异常，问题只是偶然重现，而且只能在正式环境上重现，测试环境始终没有重现问题。
三.问题分析定位过程
1.熟悉客户系统，了解问题重现方式，发现流程数据丢失需要客户操作很多次才会出现一次，重现概率比较低；
2.熟悉客户代码，发现客户的逻辑流里面存在嵌套事务，且业务操作和流程操作在同一个事务里面，对流程的操作在一个子事务里面，逻辑流里面事务设置都是接收外部事务，且同步join方式执行，没有新开事务的情况，也不存在事务图元不匹配的情况。
3.分析报错后的错误日志，发现错误是从事务同步器里面抛出来的，原因是queryWorkItemDetail报错，即找不到工作项；正常的情况下，工作项不可能不存在，因为执行到事务同步器的时候，事务必定已经提交了，而此时查询工作项肯定可以查询到，但是目前的错误情况下，工作项不存在，即根据错误日志可以推断出：
事务已经提交，但是数据没有入库。
4.一开始对事务同步器理解不够深刻，以为用户调用了事务管理器的commit操作就会触发同步器的方法，所以一开始怀疑用户可能是事务使用不当，事务管理器的begin,commit不匹配之类的情况导致事务没有正真提交，数据没有入库，所以需要验证用户是不是正真做了事务提交；
5.验证事务是不是正真做了提交：
添加日志，在逻辑流里面的事务提交图元前后打印出事务状态，通过这个状态就能判断出事务管理器方法是不是存在不匹配的情况，同时在事务同步器里面打印出流程实例，活动实例，工作项实例的ID以及状态，线程ID，请求ID之类的信息，方便问题重现后定位问题；我们判断事务状态的目的是：
如果用户正真做了提交，而数据没有入库，说明和产品存在一定关系，如果用户没有做事务提交，则是用户代码的问题，这样我们就可以根据这个状态进行2个大的方向定位。
6.分析错误日志，对比正确情况和错误情况，发现打印出的事务状态2种情况是一样的，提交前是活动状态，提交后是无事务状态，说明用户正真做了事务提交，即用户使用的事务管理器begin，commit是匹配的；而且分析事务同步器里面打印出的流程实例，活动实例，工作项实例ID及状态也都是一样的，不存在异常情况，但是数据就是没有进入到数据库；
7.由于事务管理器的使用方式没有问题，问题又回到原点；后续只能通过大量重现问题，仔细分析日志，看还能否找到其他的蛛丝马迹；由于这个问题是偶然重现，所以我们怀疑可能跟线程是否有关系，我们拿到大量的错误日志后，仔细查找这个问题是否和线程相关，发现他们存在一定的联系，我们分析日志得到规律是：
如果一个线程出错后，后面所有由这个线程处理的逻辑流，流程数据都丢失，且有一个线程丢失的流程数据达8次之多；
8.由于客户现场不能对正式环境进行远程调试，再加上测试环境一直重现不了，所以即使我们怀疑是线程问题，但是也无法进一步走下去。
9.经过讨论会之后，我们开始定位数据库连接是否存在问题；后续我们还是通过打日志的方式来判断连接是否存在问题；我们在BPS获取连接的入口打印连接的实现类，连接的状态等信息；同时在事务管理器里面增加日志，在连接的setAutoCommit,close,commit方法上增加日志；
10.分析日志：
对比正确日志和错误日志可以发现，正确情况下，Connection的autoCommit状态是true，错误情况下，Connection的autoCommit状态是false；在正确情况下，Connection的autoCommit状态是true，我们怀疑用户的was环境存在问题，因为Connection受事务管理之后，autoCommit状态一定是false，所以我们验证用户的环境是否是正常的；我们使用JSP做了最简单的验证：
开启事务，拿到连接，执行第一条sql，然后执行第二条sql，然后抛出异常，然后再执行第3条sql，最后提交，抛出异常则回滚，部署到用户的测试机器上验证，发现客户的服务器并没有回滚，前2条数据入库了；所以我们断定客户的环境出了问题。
11.后面一天我们都在修改was服务的配置，以为是数据源配置错了，导致数据库连接不受事务管理；折腾了一天之后，最后发现was环境下，即使外部开了事务，Connection的autoCommit状态就是true，不像tomcat，Connection受事务管理之后，autoCommit是false；
12.根据日志，如果说Connection的autoCommit状态是true是正确的，那么Connection的状态是false则可能就会存在问题；因为正确日志和错误日志只有这个地方存在区别；所以这个时候我们怀疑是连接坏了；继续分析日志，发现日志里面有在逻辑流里面调用了setAutoCommit的方法，用户代码将autoCommit属性设置了false，所以我们去走查用户代码，找到调用setAutoCommit的地方。
四.解决问题
1.找到用户代码之后，询问当事人为什么需要将Connection设置成false，当事人也说不出正确的理由，而且还说这个可以去掉，他只是复制的；所以我们将这行代码注释好之后，部署到测试服务器验证；同时验证打补丁之前和打补丁之后的测试环境，此时，则是环境能重现问题了，然后打上补丁之后，问题未能重现。
第二天将补丁打到生产环境，问题也未能重现，问题即解决。
2.在问题的验证过程中，有人提出，在was容器下，Connection的autoCommit状态无论是true或者false对事务管理器没有任何影响，因为通过走j2ee事务的标准接口，在was容器下，无论autoCommit的状态是true还是false，事务管理器都是正常的；
3.第二天我们对这一问题进行了验证，发现在was环境下，通过j2ee事务的标准接口使用事务，Connection的autoCommit状态true或者false，标准接口的事务确实不受影响；所以从另一个方面来说，eos的事务管理器对Connection的autoCommit状态为false这种情况支持的不够完善；
五.结论
1.从解决问题的角度，我们不建议用户直接将Connection的autoCommit设置为false，理由就是这样破坏了数据库连接；如果用户需要将连接设置为false，则需要在用完连接后，将连接的状态设置回去；或者直接在外层使用事务。
2.从产品的角度，由于标准接口true或者false2种情况都支持，所以也可以说是EOS的事务管理器支持的不完善，在特定的环境下，事务管理器应该支持这2种情况。
EOS6中配置C3P0数据源自动重连方案
文章 > hanning > 文章详情
EOS6中配置C3P0数据源自动重连方案
hanning 发表于9个月前 来自话题 #应用开发平台（EOSPlatform）# ·
116 浏览
【适用范围】、Tomcat、Jboss、Oracle
【问题描述和定位】在使用的时候，启动了Server后，如果网络出现问题Connectionreset异常，Oracle数据库连接断了后就不能进行操作了，需要重新启动Server。
那么，怎样配置可以避免重启Server，特别对于生产环境而言，需要尽可能的避免重启。
【解决方案和步骤】
1、Tomcat：
在EOSGovernor控制台的配置->数据源中，选中某数据源，点击修改，将“连接重试次数”默认值-1修改为1，点击“确定”保存。
重启Server。
或者直接修改目录D:
\primetonfor3207_platform\eosserver\working\eos-default\config下文件中DataSource的配置：
-1修改为 1
2、JBoss：
修改$JBOSS_HOME\server\default\deploy下的，将默认的数据源配置改成如下（与EOS5环境下配置类似）：
EOSDefaultDataSource:
1521:
pso
eos60
eos60
5
100
5000
15
select1fromdual
select1fromdual
【备注】
修改这个配置还可以解决如果系统中需要多数据源的话，在这个文件中增加一个local-tx-datasource配置；
上面的配置可能对系统访问数据库的性能有影响，有可能每次拿数据库连接的时候都会自动调用这个sql语句；
Weblogic、Websphere等应用服务器也应该提供了类似的自动重连机制，可以进到它们的控制台查看。
EOS异常处理方法
异常获取
EOS的异常获取分为两种，一种是在逻辑流中获取异常，另一种是在java代码中获取异常。
1.在逻辑流中获取异常
如上图所示，开发人员需要在特定的图元上通过添加异常线并添加异常抛出图元（在左侧工具面板中的高级中）的方式来获取特定的异常信息。
异常抛出图元需要开发人员先在构件包的配置文件中加入自定义的异常信息，对图元进行配置是选择相对应的ERRORCODE和ERRORMESSAGE。
ERRORMESSAGE可以定义变量，以{0},{1}的方式来进行变量绑定。
配置文件路径：
配置/resources/exception/。
该配置支持中文并自动转码，同样在也支持国际化的配置。
对于异常处理图元更详细的说明可以在EOSStudio的帮助文档中找到，
具体路径：
EOS 帮助文档->技术参考->EOS基础参考手册->逻辑流->逻辑流编辑器->异常抛出。
2.在java代码中获取异常
EOS提供了默认实现的EOSException。
当特定的springbean或者运算逻辑图元需要抛出异常，可以直接在代码中通过newEOSException的方式来抛出异常。
该异常提供了多种构造方法，常用的是EOSExceptioncode,params）。
Code是在配置文件中已经配置好的，params参数包含了message中的变量绑定。
异常处理
这里只介绍ajax调用逻辑流返回异常处理的方式。
首先，当ajax调用逻辑流时逻辑流发生异常，ajax仍然会执行成功。
因此异常的捕获会在success事件中进行。
另外exception对象中的message包含了所有的异常信息，所以需要对message进行处理。
EOS抛出的异常默认会使用换行符分隔。
处理示例如下：
（{
url:
"",
type:
"POST",
cache:
false,
success:
function（text）{
if（typeof=="undefined"）{
alert（"doSuccess!
"）;
}else{
var message= var strs=（"\n"）;
alert（strs[0]+"\n"+strs[1]）;
}
}
}）;
异常获取
EOS的异常获取分为两种，一种是在
升级会员 