sshe源码分析——全局架构

在Web.xml中


<!-- 需要拦截的JSP -->

<filter>

<filter-name>sessionFilter</filter-name>

<filter-class>sy.util.base.SessionFilter</filter-class>

<init-param>

<param-name>include</param-name>

<!-- 在securityJsp这个文件夹下面的所有JSP页面,都需要有session才能访问,可以配置多个,用英文半角逗号分割 -->

<param-value>securityJsp</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>sessionFilter</filter-name>

<url-pattern>*.jsp</url-pattern>

</filter-mapping>

sessionFilter监听的网址中如果包含Include里的部分,则需要session才能访问

效果:


<!-- 用户上下线监听器 -->

<listener>

<listener-class>sy.util.base.OnlineListener</listener-class>

</listener>

OnlineListener 会监听在线用户上线下线

效果:

在struts.xml中


<!-- session拦截器 -->

<interceptor name="sessionInterceptor" class="sy.interceptor.base.SessionInterceptor" />

<interceptor-stack name="sessionStack">

<interceptor-ref name="encodingStack"></interceptor-ref>

<interceptor-ref name="sessionInterceptor">

<!-- doNotNeedSessionAndSecurity_ 开头的和doNotNeedSession_ 开头的方法不拦截 -->

<param name="excludeMethods">doNotNeedSession_*,doNotNeedSessionAndSecurity_*</param>

</interceptor-ref>

</interceptor-stack>

sessionInterceptor拦截非jsp后缀的

效果:


<!-- 权限拦截器 -->

<interceptor name="securityInterceptor" class="sy.interceptor.base.SecurityInterceptor" />

<interceptor-stack name="securityStack">

<interceptor-ref name="sessionStack"></interceptor-ref>

<interceptor-ref name="securityInterceptor">

<!-- doNotNeedSessionAndSecurity_ 开头的和doNotNeedSecurity_ 开头的方法不拦截 -->

<param name="excludeMethods">doNotNeedSecurity_*,doNotNeedSessionAndSecurity_*</param>

</interceptor-ref>

</interceptor-stack>

</interceptors>

securityInterceptor检测权限

效果:


<global-results>

<!-- 没有session -->

<result name="noSession">/error/noSession.jsp</result>

<!-- 没有权限 -->

<result name="noSecurity">/error/noSecurity.jsp</result>

<!-- struts抛异常 -->

<result name="strutsException">/error/strutsException.jsp</result>

</global-results>

<global-exception-mappings>

<exception-mapping result="strutsException" exception="java.lang.Exception"></exception-mapping>

</global-exception-mappings>

Action结构:


其他Action通过继承BaseAction并传递相应Service来获得共有功能

包括统一命名的字段,以及基础的CUID,json处理等

Service结构:


其他Service通过继承BaseService来获得基础CUID

ServiceImpl结构:


BaseServiceImpl中注入了BaseDao

另外还有个InitServiceImpl,用来初始化

通过读取配置文件中的initDataBase.xml来写入数据库

SAX方式读取,并使用了XPath

页面部分,一个公共加载页,inc.jsp,包含公用功能及js库

登陆后的main页面是一个easyUI的layout

上面为账户相关

左边为导航菜单

中间为easyUI-tab,每个tab都是一个iframe

还有model部分:

对easyui需要的格式进行了对象封装

http://www.cnblogs.com/gcg0036/p/4390381.html

时间: 2024-10-10 06:34:17

sshe源码分析——全局架构的相关文章

spring transaction源码分析--事务架构

1. 引言  事务特性 事务是并发控制的单元,是用户定义的一个操作序列.这些操作要么都做,要么都不做,是一个不可分割的工作单位.通过事务将逻辑相关的一组操作绑定在一起,以便服务器 保持数据的完整性.事务通常是以begin transaction开始,以commit或rollback结束.Commint表示提交,即提交事务的所有操作.具体地说就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去,事务正常结束.Rollback表示回滚,即在事务运行的过程中发生了某种故障,事务不能继续进行,系统将

Django REST framework之序列化组件以及源码分析+全局、局部Hook

序列化两大功能 a.对queryset类型进行序列化 b.对用户请求的数据进行校验 a.对queryset类型进行序列化 举例说明: 表设计 1 from django.db import models 2 3 4 class UserGroup(models.Model): 5 title = models.CharField(max_length=32) 6 7 8 class UserInfo(models.Model): 9 user_type_choices = ( 10 (1, '普

转:Backbone源码分析-Backbone架构+流程图

作者:nuysoft/高云/[email protected] 原文链接:http://www.cnblogs.com/nuysoft/archive/2012/03/18/2404274.html JSMVC职责划分 M 模型 业务模型:业务逻辑.流程.状态.规则 (核心)数据模型:业务数据.数据校验.增删改查(AJAX) V 视图 (核心)视图:定义.管理.配置 模板:定义.配置.管理 组件:定义.配置.管理 (核心)用户事件配置.管理 用户输入校验.配置.管理 C 控制器/分发器 (核心)

nginx源码分析:架构解析

nginx启动流程: 根据上面的手稿得知,nginx在循环中调用ngx_process_events_and_timers该函数来处理事件,在该函数中,最主要的一个操作是调用了ngx_process_events函数,该函数是一个宏定义,然后我再工程里面搜一下ngx_event_actions,结果如下: ngx_event_action在每一个多路复用后端中被分别赋值. 在ngx_event_accept函数中,没接收到一个新的连接,就会建立一个ngx_connection对象,并将ngx_r

sshe源码分析&mdash;&mdash;权限管理的后台部分

数据库结构: 用户跟组织:多对对 用户跟角色:多对多 组织:有上级组织 资源跟组织:多对多 资源跟角色:多对多 资源:有上级资源 资源:有资源类型 BaseDaoImpl中用了Hibernate原生的session: @Repository public class BaseDaoImpl<T> implements BaseDaoI<T> { @Autowired private SessionFactory sessionFactory; /** * 获得当前事物的sessio

RMI 系列(02)源码分析

目录 RMI 系列(02)源码分析 1. 架构 2. 服务注册 2.1 服务发布整体流程 2.2 服务暴露入口 exportObject 2.3 生成本地存根 2.4 服务监听 2.5 ObjectTable 注册与查找 2.6 服务绑定 2.7 总结 3. 服务发现 3.1 注册中心 Stub 3.2 普通服务 Stub RMI 系列(02)源码分析 1. 架构 RMI 中有三个重要的角色:注册中心(Registry).客户端(Client).服务端(Server). 图1 RMI 架构图 在

Caching-缓存架构与源码分析

Caching-缓存架构与源码分析 首先奉献caching的开源地址[微软源码] 1.工程架构 为了提高程序效率,我们经常将一些不频繁修改,但是使用了还很大的数据进行缓存.尤其是互联网产品,缓存可以说是提升效率优化第一利器.微软为我们实现了俩种缓存方式:内存缓存.分布式缓存.个人理解如果缓存在前端电脑内存的缓存叫做内存缓存,如果缓存在其它设备上,那么叫做分布式缓存. 俩种缓存方式的优缺点 我开发程序经历过三个时间点,开始的时候从来不使用缓存,之后将数据缓存在内存中,最后使用分布式缓存.内存缓存的

JDK源码分析之concurrent包(一) -- Executor架构

Java5新出的concurrent包中的API,是一些并发编程中实用的的工具类.在高并发场景下的使用非常广泛.笔者在这做了一个针对concurrent包中部分常用类的源码分析系列.本系列针对的读者是已经对并发包中的Executor框架和工具类有所了解并懂得如何使用的人群,如果对并发包还不了解的朋友,请先做些了解.网上对这方面的讲述有丰富的资源. 本篇博文是第一期,首先对Executor架构做一个概述.这里只简单介绍接口和类的继承.使用关系. 盗用一张类图来描述结构: 解析: Executor是

Docker源码分析(一):Docker架构

[编者按]在<深入浅出Docker>系列文章的基础上,InfoQ推出了<Docker源码分析>系列文章.<深入浅出Docker>系列文章更多的是从使用角度出发,帮助读者了解Docker的来龙去脉,而<Docker源码分析>系列文章通过分析解读Docker源码,来让读者了解Docker的内部实现,以更好的使用Docker.总之,我们的目标是促进Docker在国内的发展以及传播.另外,欢迎加入InfoQ Docker技术交流群,QQ群号:272489193. 1