tomcat在关闭应用时，对资源做了一些清理，避免了泄露，这个工作主要是WebappClassLoader里做的，WebappClassLoader也实现自Lifecycle接口，在应用关闭时，会触发其stop方法，其中对JDBC Driver的清理，是clearReferencesJdbc方法，它检查当前WebappClassLoader加载过的，在关闭时未注销掉的JDBC Driver，给出警告信息，并强行将这些Driver反注册掉。如果servlet在初始化时注册了一个Driver，但销毁时未将这个Driver给反注册掉；这时不管是显式的通过命令来stop tomcat，还是因为设置了自动reload，而且恰好检查到应用有变，执行了reload的时候(reload也是对app context进行stop，然后再重新start)，就会被tomcat判断为泄露，给出警告并强制反注册Driver。
Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。我们选用flume对内部多个系统的日志进行信号的采集、管理和查询，目前仅实现了信息管理功能，进一步会对报警、统计等功能进行开发。
在系统中存在这样的情况：一个功能点触发的动作会引起相关一个或者多个功能点在业务上进行对应的数据处理。而到底有几个功能点要做出相应，要看客户实施了哪些需要作出响应的具体功能点。 例如：A功能点的某项业务会触发B、C、D三功能点做出回应，而客户订阅了哪些功能点是个未知数，也许客户不需要C功能点，对A功能点业务操作作出响应的仅有B、D。 根据上面的需求可以得出，设计上要尽量的松散耦合，保持各功能点的独立性。观察者模式责无旁贷的跳了出来。
quartz提供了基本的定时任务管理方法，与spring结合可以方便的使用定时任务。但quartz的弊端也显而易见，比如动态修改定时配置，定时任务的统一管理界面、调度和监控都是十分不便的。我们曾于quartz开发了定时任务的管理模块，主要针对定时任务的定时配置进行管理。技术总监徐总提出了使用easyschedule的方案，我们针对这一解决方案比较方便的解决了公司内部各信息系统的定时任务的管理和监控，以下是easySchedule的使用总结，比较简单，以下的代码实现方案主要是为了将原quartz的实现无缝的与easySchedule结合，涉及的主要是使用。明天会接接入，特别是小型web系统的接入方法做更详细的描述。
为表单建立版本表，以存放历史版本信息（包括最新版本信息）；最新版本信息存放在表单定义表中。在流程的发起以及审批时将表单版本信息带出，凡有取fromDefineId的均应替换为对应的verId。为兼容无版本管理之前的流程：如版本id为空，则取formDefine表中最新的formDefineId所对应的html、template。同时表单权限的设置需以verId为标识，而不是formDefineId为标识。 表单管理方案的缺陷：表单的更新较版本的更新更加频繁，这样会大大加重开发和运维人员维护表单权限表的任务量。
允许在有工作的情况下使用流程设计器，且不同processDefine允许对应同一formDefine，在设计器中对现有流程进行优化后，保存并发布后processDefineId、name不变的情况下更新deploymentId、version，同时将老的deploymentId及version存储在其他表中供老流程中未运行结束的实例使用（也可能不需要存储。因为jbpm4中已经存储了完整版本信息，包括版本定义与运行中的版本识别。而t_bpm的运行和任务只是OA中展示所用，并不控制流转，所以可能不需要版本信息，而jbpm4的运行和任务的版本信息全部来自其本身），并允许流程管理员在不同版本之间切换，即可以选定新建工作时该流程是哪一版本（这一功能则需要存储每一次部署后的版本信息）。
简单方案实现较简单，但不支持前后置任务和表单的更新，适用简单的线性流程； 完整方案考虑到了表单的更新和前后置任务的执行，实际是在未打开页面前就将历史表单数据取出，根据表单权限将必填字段由批量审批人统一填写后，再循环单一审批逻辑，达到批量审批的效果。 两种方案目前均不支持下一步节点或下一步审批人各不相同的情况。
BPM、基础数据、应用系统分别独立部署，并通过PI、服务注册中心等进行通信； 另外，也可以考虑BPM和基础数据（或与OA部署在一起），所有其他应用系统的审批在OA中进行，与现有费控审批在OA中可以办理相似，可以减少接口开发和异构系统之间的通信。
由于OA系统档案查询模块没有对查询者的权限进行完整验证，导致攻击者可以利用该漏洞在查询模块通过修改工号的方式遍历公司所有员工的个人信息。
注解相当于一种标记，在程序中加了注解就等于为程序打上了某种标记，没加，则等于没有某种标记，以后，javac编译器，开发工具和其他程序可以用反射来了解你的类及各种元素上有无何种标记，看你有什么标记，就去干相应的事。标记可以加在包，类，字段，方法，方法的参数以及局部变量上。
因邮件服务器不稳定导致在仅发送一次的情况下也会向邮件收件人发送邮件，且同一封邮件的收件人（包括抄送、密送）可能部分收到邮件、部分收不到邮件。针对以上的问题，我们将重发机制去除，仅针对不合法邮件（即服务器上不存在的邮件地址）进行剔除，剔除后再进行发送
在工作流的一张表单里可能会有多个步骤上传附件，在用户的待办中往往会存在多条带有附件的任务，如果一一打开并且点击下载链接下载，不仅费时，而且繁琐，用户体验较差。 OA系统采用的是FastDFS做为文件服务器，FastDFS的Java客户端提供了上传、下载等功能供调用。在我之前的文章里对此有描述，目前已有的代码有对文件的批量上传功能，但下载的参数往往是针对单个文件。比如单个文件的下载方法如下：/
目前对会签的表单我们采用了两种不同的方案，也代表两种不同的风格。第一种是moss风格，第二种是通达风格。Moss风格不共用会签区，不同的会签人会签意见签署区不同。这种风格的会签人是固定配置在节点上的，如果会签人不固定，那么会签区表单权限控制就会出现混乱；通达风格则是属于共用会签区的形式，不同会签人都在同一个输入框中输入审批信息。点击审批时，审批人、审批时间和审批意见存储在另外一张表里，展示的时候使用拼接html的table的形式展示在相应位置。
JBPM的DBID自增长的实现
问题逐渐聚焦在查询方法上。这个关联查询出现问题可以肯定的是不是用户信息有多条，就是档案信息有多个。但从业务角度讲，用户和档案相对于staffid都是全局唯一的。我查询了档案数据，发现档案果然就是两条——HR在使用OA为新入职员工创建档案使用的是excel导入的追加功能（导入有追加和更新两种，如果选择追加，则不做判断，直接插入新记录），而新上线的功能又会在创建用户时同步创建一个空档案，从而产生两条档案记录，也影响到了用户的查询。
基于struts2 拦截器ResultType为chain的Action之间数据传递对表单页面的打开速度进行优化
关于ueditor的select控件的key为空时出现校验bug的修复
去年八月份公司启动了针对管理人员的职业经理人培训，邀请外培老师以及公司高管担任讲师。培训分为针对基层经理的初级启航班、总监级的中级远航班和总经理及以上级别的高级领航班。其中初级班一期培训从公司300多位基层经理中选拔，非常有幸被选中参加一期职业经理人培训。一期培训被老总称为公司黄埔的一期学员，在这次培训中先后系统学习了成为管理者、项目管理、财务管理、时间管理、产品管理、团队建设、有效沟通等十余个模块，有的模块又分成了几次课程，共计一百多个学时，总周期为八个月。另外还参加了基于有效沟通和产品管理的两次项目实战。为了这次培训也放弃了很多周末休息和陪伴老婆和儿子的机会，不管如何，收获还是很多。
高级查询功能是针对所有流程及表单数据的查询入口，作为工作流报表的暂时性替代功能，对于领导和相关流程的业务单位来说十分重要。高级查询功能提供了包括了流程名称、发起人、发起人所属部门等的基本条件查询以及可用作查询条件（是否可用作查询条件在列定义中设置，选中某个表单后，可供选择的列自动展示，并且根据列定义中的数据格式提供不同的查询方式，比如模糊匹配、比如日期的区间查询等）的高级条件查询，通过组合查询条件得到想要的查询结果。 由于高级查询一直存在分布的问题，究其原因主要是前端的展示与后台的分布难以协同，oaGrid或者原生的kendoGrid均无法展现动态列（这个问题网上确实没有例子，有gridView可以实现动态列的范例）。高级查询先后经历无分页（用<table>标签拼接）、伪前端分页等一系列演化。
我们使用js callback的实现，当前页面的调用页面非空且未关闭时，我们就直接调用页面中的js方法实现其局部的刷新。
通过使用JBPM的命令模式，我们愉快地实现了线程安全的自由流功能，而不需要做任何额外的线程、事务控制等底层的逻辑处理，而将这种处理全部交给核心引擎。 我们基于设计模式的思路简单剖析一下JBPM的命令模式实现。命令模式主要有以下三种角色，命令Command、命令的接收者Receiver(命令实际的作用者)、命令的控制器（执行命令）。命令模式也主要是用于调用者（Invoker:流程引擎）和被调用者（Receiver:流程执行环境）之间通过命令(Command:GoBackCommand)解耦，实现代码清晰、可扩展、易维护的一种思想。
泛型是一种将参数类型作为参数实现更广泛应用的一种机制，在C++、C#中有所谓模板与泛型的机制是相似的。Java中的泛型与其他语言的泛型实现机制不同，是一种基于擦除的伪泛型。比如List<String>与List<Integer>在代码编写期间是不同的，但在编译好的字节码文件中却都被转化为原生类型。我们知道JDK1.5出现之前类似泛型的实现是通过继续以及类型强转实现，在字节码文件中泛型好像又回到了JDK1.5出现之前。关于Java为什么使用这种机制实现泛型，不同的人有不同的解决，比如效率等。但比如我们上述代码中的两个方法，如我们将其中一个返回值改为其他类型，编译是可以通过的。文章又对所谓的特征签名（源码签名，只包含参数类型、个数等）和方法描述（字节码签名，包括参数列表和返回值、原生类型等）进行了解释。重载是根据字节码的特殊签名，而返回值不参与特殊签名；但原本报类型擦除错误的方法加上不同返回值却可以通过编译，这是因为只要两个具有不同方法描述的方法均可以存在于同一个字节码文件中，所以通过了编译。另外，文章还对为什么类型在编译后被擦除，我们却可以通过反射等机制得到其原始
之前一直从事C/S的开发，关于B/S用到的一些技术是不熟悉的，现在在逐步学习中，希望通过及时总结加强理解和记忆。目前开发的系统使用的主要是JQuery、Stuts2、Spring。 关于自由流后端及Jbpm的实现我会在另一篇博文中介绍，这里只介绍我在前端使用html及JQuery中遇到的问题以及对我来说不常使用的知识点。
在我们的工作流系统里已经有工作移交的功能，工作移交常用于用户离职、异动、岗位变化、长期不在岗位等情况，将已经分配给该用户的工作移交给其他用户。移交的本质是更改正在审批中的任务的审批人。而委托和转交功能中的转交功能与移交相似，移交功能由管理员发起，而转交则是由当前审批人主动发起的改变审批的行为。在日常运维中，经常出现类似这样的场景，某一工作被错误的移交到我手里，或者是我现在已经不办理类似流程了，我想主动的将该流程转给他人办理，这就是转交。另外，用户请假、外出、出差或针对某些低级别的流程（按照流程规定需要高层审批，比如总监级的请假单、加班单会由越级领导高级副总裁审批，而高级副对类似的单子不愿意去审批）希望委托他人审批，这即是一种事前的委托，而转交或转办也被称为审批中的委托。
在阅读源码的时候，我的建议不是从第一个源代码依次读起，而应该选择一个入口。通过这个入口一步步进行；或者通过我们在应用中所引用的功能接口，逐步深入，相互映射关联，最终形成一张相对完整的知识网络。 使用jbpm的都知道，jbpm的核心是流程引擎，流程引擎通过配置文件定义。我们一般通过以下方式得到流程引擎
本文中所述的离职模块：离职模块共分三个部分，分别为离职信息新增、审批中离职、已结束离职三个子模块。离职信息新增功能主要是针对被动离职，也即单位劝退、辞退或单方面解除合同的离职信息新增，此类离职一旦保存即可认为是已结束离职，所以不像审批中离职查询逻辑中十分清晰，已结束离职需要关联多表进行查询。在测试系统中进行测试时，我们发现直接执行已结束离职查询sql，在数据量为17条时，约1s，实际较慢，但尚可接受。该功能在正式系统上线后，离职数据约400条，用户简单在前端计时，约需十余秒等待，用户体验已经极差，需要从逻辑或数据库技术角度进行优化
问题1.Column 'username' in field list is ambiguous 问题2.sql：截取中出现的问题 问题3：大批量邮件漏发问题的测试、与分析
问题1：can not be cast to javax.servlet.Filter 问题2：MYSQL里的ISNULL、IFNULL、NULLIF 问题3：MySQL关于txt格式字段的优化 问题4：tools.jar not found
SQL state [HY000]; error code [3]; 问题分析
Redis2.1.0：Could not get a resource from the pool的分析及建议解决方法
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
