jalor5是一套功能强大的框架，该框架集成了spring、mybatis、cxf、日志、异常等组件，和其它未提及的部分组件，如消息组件。
它还自带了权限管理，内容管理，国际化等功能，该框架在项目开发中起到了缩短项目周期和降低技术难度的功能。
虽然jalor5的开发和使用都有大量文档，但是我觉得一个从未接触过jalor5甚至未接触过Spring框架的人来说，单单靠jalor5的文档，
还是会遇到很多的问题，比如环境搭建，数据流的方向等。jalor5是在jdk1.5的环境下开发的，文档中说使用其它的jdk版本或许会存在问题，
但是如果用jdk1.5的话jalor5会有错误，而且在新建项目中也存在一些细节与文档上的差别，文档中的部分例子不够全面，使得在学习过程中
遇到了很多小的但是又难以解决的问题。就算环境搭建都没问题了，在建好项目了之后也会遇到个别的问题，比如数据库的初始化、包名的固定
命名、请求url的写法，各个应用层代表的意思，接口层中path注解的命名都会遇到各种不同的问题。下面我说说我遇到的问题和解决方法：
问题（仅是我遇到的，大家使用的时候不一定会遇到）：
1、lib包的编译问题，刚开始的时候提示编译版本不对，要使用jdk1.5版本编译。解决方法：按照提示改成jdk1.5编译即可（改了之
后再切换回jdk1.6错误不提示了，很是奇怪）。
2、数据库初始化问题。jalor5的使用必须初始化数据库，而oracle的安装和导入数据脚本是必要的，但是导入脚本过程中也要注意
修改脚本中的appname和scope的名字，我是只改了appname为自己的应用程序名即可。因为jalor5的后台管理菜单的内容是
根据appname去获取的，所以这一步是必须的。
3、新建项目中包的命名，我自己随便命名，结果程序一直报错。解决方法很简单，修改包名为com.huawei.it打头即可，当然相应的
层命名必须包含有dao、service等全小写的单词，因为spring配置是要去扫描这些配置的路径的。
比如service的包命名：com.huawei.it.yq.report.service 其中yq是应用程序名、report是模块名、service代表服务层。
4、api接口层、impl实现层、test测试层、test测试支持层（test.support）、web层的概念：
api接口层：在这一层中全部放置接口类，接口类包括dao数据库打交道层的接口、service服务逻辑层的接口；还放数据库表
对应的java类对象，即vo对象。该层的service接口需配置@Path注解和@Produces注解。
impl实现层：依赖api层，在这一层中全部放置api层接口的实现类和dao接口对应的映射xml文件（mybatis文件）。在service实现类中必须
使用@Named注解。在service实现类中用到dao接口要使用@Inject注解。
test测试层：依赖impl层、test测试支持层，使用junit4来编写测试类，测试service实现类是否可用可行。这样子不用每次都启动tomcat来测试。
test测试支持层：该层只存放两个配置文件：xx.test.support.beans.xml、xx.test.support.configs.xml，需修改数据库连接代码等。
web层：该层最重要的就是web.xml配置文件和application.xml文件，还有config文件下的几个配置文件。该层没有何人其它文件，
它的存在只是为了加载我们的应用程序api和应用程序impl，tomcat启动的时候就会把api、impl层编译装载，它们就全部在一个web里面了。
5、分页传递参数最好以对象的形式去传递参数。
6、vo、dao、dao的映射xml文件的自动生成，在路径中选择api层中的src/main/java路径，包名必须以com.huawei.it打头。
7、html页面、js文件的代码编写。css文件的引用。
8、国际化信息管理，当添加国际化信息后，需要清空缓存才能显示，这点要注意。
而我在这两周的时间学习了jalor5的一些功能，主要是我们当前项目需要用到的，主要知识点有：
1、IGrid表格的数据显示，数据来自oracle数据库。
2、IGrid中实现数据的批量添加、修改、删除。
3、IGrid实现过滤功能，有降序、升序，过滤条件有等于、大于、包含等，单选按钮、多选框选择过滤等。
4、from表单的数据显示、修改、增加记录的实现。
5、表单主要用到文本框控件、单选按钮多选按钮控件、时间控件、下拉选择控件等。
对jalor的数据流方向有了一定的了解，知道模块开发的流程、功能的开发流程，从项目的搭建、数据库的连接、前后台的数据交互都有了一定的了解，我知道jalor5的很多
知识都还需要学习，但是我觉得不需要全部都精通jalor5再去做项目，没有必要。其它的知识点可以在需要的时候再去学习，这样可以一边做项目一边熟悉，再不懂的可以请求jalor5
Jalor3 中沿用的古老的七层Pattern架构，产生了大量吃闲饭的冗余代码，想必很多人都深有体会，恨之入骨。我们可不敢站在人民的对立面，于是我们决定精简代码层次，推出Jalor5框架，来解决大家的心头之恨。正如大家知道的，Jalor5 最终采用 展现层/服务层/数据访问层/数据库层的精简4层结构，不过这个四层架构的来历也并不简单。刚开始的时候，我们团队内部对新的架构存在一些分歧，部分团队成员坚持认为应该在展现层和服务层中间增加服务Facade层，理由是便于在这一层上进行权限控制和服务暴露，如果没有这一层，由于服务层之间的相互调用，权限将在一个网状结构中传递，众所周知，网状结构是难于控制的。
举个简单的例子：A服务，调用了B服务和C服务来进行一个完整的操作，在没有服务Facade层的情况下：
1. 如果ABC三个服务都控制了权限，难道我们要给用户授予ABC三个权限，用户才能使用A服务？这显然是不可接受的
2. 那我们换个方式：利用技术手段，只在A上控制权限，忽略BC的权限控制，有时候B操作是个关键操作，必须强制进行权限校验，也是不可接受的
3. 如果A是个批量保存的操作，他调用批量更新的操作B和批量新增的服务C来完成任务，这时A不控制权限，而交由B和C分开控制，对于没有新增权限的人，如果提交的数据中只有更新数据的，这个操作仍然可以成功。
4. 更复杂的情况，A服务是不控制权限的，B服务又调用了D服务，C服务又调用了E服务，或者交叉起来
显然问题的复杂性在一步一步上升。
我们来做个比喻，你去一个大的景点玩（A服务），买了张门票，到里面的大部分景点（B、C）是不需要再买新的门票的，但是有一些特殊景点可能需要。有的大景点是免费的，里面的小景点（B、C）要分开买票。更复杂的情况是，大景点（A）是免费的，里面有两个收费的中型景点（B、C），中型景点里面又有小景点（D、E），这些小景点只认对应的中型景点的门票（D只认B门票，E只认C门票）。
增加一个服务Facade层可以有效的解决这个权限的问题，权限仅在Facade层控制，也就不存在网状问题了。但是为了这少部分的权限场景，增加这一层吃闲饭的到底划不划算？我们可不敢再一次站在人民的对立面。
我们徘徊在大中小景点门前，思绪如那团网状的乱麻，我们真的要接受这个一刀切的超级联票吗?我们真的要放弃心底对极致简约的追求吗?
如果你看了标题，你就知道上面两个问题的答案是否定的。
有的时候我们走入了困境，总希望遇到可以指点迷津的大师。我时常梦见，大师拄着禅杖，道一声哦米拖佛，说施主你只需如此这般(此次省略411个字)便可。
其实，无论你指望，或者不指望，大师就在那里，也不曾走远，只是你看不见，也摸不着。EJB 的设计者中就有这样的大师。我们回想起 EJB 中的事务传播模型，发现 EJB 的事务就是在一个类似的网状结构中传播。
参考前辈的方案，我们将每个服务对权限的控制策略分成了几种：Mandatory（强制校验）、Required（前面校验了我就不校验，否则校验）、IgnoreAll（忽略后继所有的权限校验） 等几个级别，并引入了栈、桢来管理传播关系，权限拦截器根据服务的权限控制策略来进行必要的控制，这个问题也就迎刃而解了。
以上述例4来说，其伪代码如下：
java代码
public void a(...){
...
b();
c();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void b(...){
d();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void c(...){
e();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void d(