监听器

很久以前，addEventListener() 的参数约定是这样的： addEventListener(type, listener, useCapture) 后来，最后一个参数，也就是控制监听器是在捕获阶段执行还是在冒泡阶段执行的 useCapture 参数，变成了可选参数（传 true 的情况太少了），成了： addEventListener(type, listener[, useCapture ]) 去年年底，DOM 规范做了修订：addEventListener() 的第三个参数可以是个对象值了，也就是说第三个参数现在可以是两种类型的值了： addEventListener(type, listener[, useCapture ]) addEventListener(type, listener[, options ]) 这个修订是为了扩展新的选项，从而自定义更多的行为，目前规范中 options 对象可用的属性有三个： addEventListener(type, listener, { capture: false, passive : false, once: false }) 三个属性都是布尔类型的开关，默认值都为 false。其中 capture 属性等价于以前的 useCapture 参数；once 属性就是表明该监听器是一次性的，执行一次后就被自动

Java基础知识笔记-12-事件处理 学习组件除了要熟悉组建的属性和功能外，一个更重要的方面是学习怎样处理组建上发生的界面事件，当用户在文本框中输入文本后按回车，单击按钮，在一个下拉式列表中选择一个条目进行一个条目等操作时，都发生界面事件，例如，用户单击一个确定或者取消的按钮，程序可能需要做出不同的处理。 1 事件处理模式基础 任何支持GUI的操作环境都要不断地监视按键或点击鼠标这样的事件。操作环境将 这些事件报告给正在运行的应用程序。如果有事件产生，每个应用程序将决定如何对它们做出响应。在Visual Basic这样的语言中， 事件与代码之间有着明确的对应关系。程序员对相关的特定事件编写代码，并将这些代码放置在过程中，通常人们将它们称为事件过程（event procedure) 例如，有一个名为HelpButton的Visual Basic按钮有一个与之关联的HelpButton_Click事件过程。这个过程中的代码将在点击按钮后执行。每个Visual Basic的GUI组件都响应一个固定的事件集，不可能改变Visual Basic组件响应的事件集。 另一方面，如果使用像原始的C这样的语言进行事件驱动的程序设计，那就需要编写代 码来不断地检查事件队列， 以便査询操作环境报告的内容（通常这些代码被放置在包含很多switch语句的循环体中） 。显然，这种方式编写的程序可读性很差

1 监听器、过滤器和拦截器 1.1 监听器 监听器Listener，它是实现了javax.servlet.XXXListener接口的服务器端程序，它也是随web应用的启动而启动，只初始化一次，随web应用的停止而销毁。主要作用是：做一些初始化的内容添加工作、设置一些基本的内容、比如一些参数或者是一些固定的对象等等。 在javax.servlet.XXXListener接口中定义了2种方法： void contextInitialized(ServletContextEvent sce) 监听器的初始化 void contextDestroyed(ServletContextEvent sce) 监听器销毁 1.2 过滤器 Servlet中的过滤器Filter是实现了javax.servlet.Filter接口的服务器端程序，主要的用途是过滤字符编码、做一些业务逻辑判断等。其工作原理是，只要你在web.xml文件配置好要拦截的客户端请求，它都会帮你拦截到请求，此时你就可以对请求或响应(Request、Response)统一设置编码，简化操作；同时还可以进行逻辑判断，如用户是否已经登录、有没有权限访问该页面等等工作，它是随你的web应用启动而启动的，只初始化一次，以后就可以拦截相关的请求，只有当你的web应用停止或重新部署的时候才能销毁。 在javax.servlet

配置监听器 @Component public class StudentRestListener extends AbstractRepositoryEventListener<Student>{ @Override protected void onBeforeCreate(Student entity) {//新建前 log.info("新建前操作"); } @Override protected void onAfterCreate(Student entity) {//新建后 log.info("新建后操作"); } @Override protected void onBeforeSave(Student entity) {//保存前 log.info("保存前操作"); } @Override protected void onAfterSave(Student entity) {//保存后 log.info("保存后操作"); } @Override protected void onBeforeDelete(Student entity) {//删除前 log.info("删除前操作"); } @Override protected void onAfterDelete(Student entity) {//删除后 log.info("删除后操作"); } }

配置监听器 public class StudentEntityListener { @PrePersist // 保存前 public void prePersist(Student student) { log.info("保存前" + student.toString()); } @PostPersist // 保存后 public void postPersist(Student student) { log.info("保存后" + student.toString()); } @PreRemove // 删除前 public void preRemove(Student student) { log.info("删除前" + student.toString()); } @PostRemove // 删除后 public void postRemove(Student student) { log.info("删除后" + student.toString()); } @PreUpdate // 更新前 public void preUpdate(Student student) { log.info("更新前" + student.toString()); } @PostUpdate // 更新后 public void postUpdate(Student

在Js中，this关键字的值是由函数调用的方式决定的，如果函数是作为对象的方法来调用，那么this的值将为这个对象，如果函数是作为独立的函数来调有物，那this的值是一个包含所有全局变量和函数的全局对象。 所有的支持W3C的事件模型的浏览器都是将事件监听器作为被赋值的元素的方法来访问，而IE中的this代表的是相对无用的全局对象。 再说说IE中的内存泄漏问题：在IE浏览器中，如果要为某个元素创建一个事件监听器，并有在监听器中使用这个元素，则在用户进入其他页面之前，这个监听器以及相关的DOM节点所占据的内存空间不会被释放。 转载于:https://my.oschina.net/u/1792175/blog/598051 来源： https://blog.csdn.net/chuomu8273/article/details/100681928

1. Spring读取xml配置文件的原理与实现 https://www.cnblogs.com/wyq178/p/6843502.html 2.首先使用xml配置文件的好处是参数配置项与代码分离，便于管理以及日后的维护和修改。 其次，xml是标准化的树节点文档，通用性强。 第三，在一个采用SSH2框架的java web项目中，容器在初次启动的时候，会先读取 web.xml ，如果 web.xml 里面配置了spring和 struts2 的监听器，则会通过监听器的配置路径找到spring和struts的配置文件。srping的配置文件是applicationContext.xml，而 struts2 的配置文件是struts.xml。至于底层解析可能是采用 dom解析 方式。 再来接着说解析后被调用的过程： 当容器启动并读取 web.xml 的时候，如果发现有配置监听器，则会先进入监听器的初始化方法，并执行里面的代码逻辑。spring监听器的配置为： <!-- spring整合 struts2 的监听器 --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!--

一.简介 Zookeeper 是Google 的 Chubby一个开源的实现，是 Hadoop 的分布式协调服务。 它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。 为什么使用Zookeeper ： 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等） 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器 ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用 ZooKeeper能帮我们做什么？ Hadoop2.0,使用Zookeeper的事件处理确保整个集群只有一个活跃的NameNode,存储配置信息等。 HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等。 二.分布式锁 分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。 所谓保持独占 ，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过 create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点

笔记 3、Servlet3.0的注解自定义原生Listener监听器实战 简介：监听器介绍和Servlet3.0的注解自定义原生Listener监听器实战 1、自定义Listener(常用的监听器 servletContextListener、httpSessionListener、servletRequestListener) @WebListener public class RequestListener implements ServletRequestListener { @Override public void requestDestroyed(ServletRequestEvent sre) { // TODO Auto-generated method stub System.out.println("======requestDestroyed========"); } @Override public void requestInitialized(ServletRequestEvent sre) { System.out.println("======requestInitialized========"); } 开始 创建好的listener 访问。传一个id过来 后台控制台输出 刷新接口页面 新建另外一个listener 实现接口，并重写两个方法

SchedulerListener 是用于监控调度器scheduler 中添加,删除定时任务或触发器等操作, 和JobListener, TriggerListener类似, 但由有不同. SchedulerListener 全局唯一, 也就是说一个Scheduler 只能配置一个SchedulerListener 监听器. 1. SchedulerListener 接口 和JobListener/TriggerListener类似, 自定义SchedulerListener 需要实现SchedulerListener接口或继承SchedulerListenerSupport, 并重写关注的方法. 这里笔者推荐使用第二种方式, 因为第一种方式需要实现方法太多. SchedulerListener 定义的接口方法, 每一个方法都是监听对应的Scheduler中定义的方法. SchedulerListener 也不会持久化到数据库, 更不支持分布式. 需要每次启动应用时注册. public interface SchedulerListener { public void jobScheduled ( Trigger trigger ) ; public void jobUnscheduled ( String triggerName , String triggerGroup ) ;