Struts

摘要：SSH=Struts+Spring+HibernateSSH不是一个框架，而是多个框架（struts+spring+hibernate）的集成，是目前较风行的一种Web应用程序开源集成框架，用于构建灵便、易于扩大的多层Web应用程序。 集成SSH框架的零碎从职责上分为四层：表示层、业务逻辑层、数据长久层和域模块层，以帮忙开发人员在短期内搭建构造清晰、可复用性好、保护不便的Web应用程序。其中应用Struts作为零碎的整体基础架构，负责MVC的拆散，在Struts框架的模型局部，管制业务跳转，利用Hibernate框架对长久层提供反对，Spring做治理，治理struts和hibernate。 SSH框架的零碎是基于MVC的。Struts 是一个很好的MVC框架，次要技术是Servlet和Jsp。Struts的MVC设计模式能够使咱们的逻辑变得很清晰，让咱们写的程序层次分明。基于Struts开发能够简化开发难度，进步开发效率。 Spring 提供了治理业务对象的统一办法，并激励注入对接口编程而不是对类编程的良好习惯，使咱们的产品在最大水平上解耦。 Hibernate 是用来长久化数据的，提供了齐全面向对象的数据库操作。Hibernate对JDBC进行了十分轻量级的封装，它使得与关系型数据库打交道变得十分轻松。 在Struts+Spring+Hibernate零碎中，对象之间的调用流程如下： Struts——>Spring——>Hibernate JSP——>Action——>Service——>DAO——>Hibernate 比方： 1.Spring的配置文件bean.xml 2.Struts的配置文件 struts.xml 3.Hibernate其中的一个配置文件： Spring框架的作用和益处: Spring框架提供了一个容器，该容器能够管理应用程序的组件，还提供了IoC和AoP机制，实现组件之间解耦，进步程序结构的灵活性，加强零碎的可保护和可扩展性。 在SSH整合开发中，利用Spring治理Service、DAO等组件，利用IoC机制实现Action和Service,Service和DAO之间低耦合调用。利用AoP机制实现事务管理、以及共通性能的切入等。 性能是整合，益处是解耦。 Hibernate中操作并发解决（乐观锁和乐观锁） Hibernate框架能够应用锁的机制来解决操作并发。 a.乐观锁 在数据查问进去时，就给数据加一个锁，锁定。这样其余用户再执行删、改操作时不容许。当占用着事务完结，锁会主动解除。 Hibernate采纳的是数据库锁机制实现乐观锁管制。 毛病：将并发用户操作同步开，一个一个解决。当一个用户解决工夫比拟长时，效率会比拟低。 b.乐观锁 容许同时更新提交，然而最快的会胜利，慢的失败。 在记录中追加一个字段值，用该字段值当做版本。当最先提交者提交后，会主动将版本字段值晋升，这样其余用户提交，会发现版本低于数据库记录目前版本，因而抛出异样提醒失败。 特点：容许用户同时解决，但只能有一个胜利，其余失败，以异样形式提醒。 SSH工作流程 a.启动服务器，加载工程以及web.xml. (实例化Lisener,Filter等组件，将Spring容器和Struts2管制创立) b.客户端发送申请，所有申请进入Struts2控制器。控制器依据申请类型不同，别离解决。 (action申请，*.action会进入struts.xml寻找配置. 其余申请，*.jsp会间接调用申请资源，生成响应信息) c.Struts2控制器依据配置调用一个Action对象解决。 整合办法一：将Action交给Spring容器 (Action对象由struts2-spring-plugin.jar插件提供的 StrutsSpringObjectFactory负责去Spring容器获取) 整合办法二：将Action置于Spring容器之外 (Action对象由struts2-spring-plugin.jar插件提供的 StrutsSpringObjectFactory负责创立，而后到Spring容器中寻找与Action属性匹配的Bean对象，给Action对象注入。(默认采纳名称匹配规定) d.Struts2控制器执行defaultStack拦截器、Action对象、Result等组件解决. e.执行Action的execute业务办法时，如果应用Service或DAO采纳Spring的IoC机制调用。 f.执行Result生成响应信息，执行后续拦截器解决 g.将响应信息输入。 本文分享自华为云社区《SSH 组合框架模式小常识分享》，原文作者：Jack20 。 点击关注，第一工夫理解华为云陈腐技术~

本文剖析的源码波及三个方面： 1  struts中应用到的动静代理：ActionProxy 和 ActionInvocation 2  struts中是如何解决拦截器和action申请的 3  struts中是如何处理结果的 每个申请都会通过Dispatcher中的serviceAction办法，这个办法中有很重要的一句代码 String namespace = mapping.getNamespace();String name = mapping.getName();String method = mapping.getMethod();//步骤1 ActionProxy proxy = getContainer().getInstance(ActionProxyFactory.class).createActionProxy( namespace, name, method, extraContext, true, false);request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, proxy.getInvocation().getStack());// if the ActionMapping says to go straight to a result, do it!// 前面再剖析resultif (mapping.getResult() != null) { Result result = mapping.getResult(); result.execute(proxy.getInvocation());} else { // 步骤2 proxy.execute();}这外面比拟重要的一句是获取proxy的这一句，从container中先获取一个ActionProxyFactory的实例，而后依据命名空间（struts.xml的package？），action的名字，办法名，上下文生成一个ActionProxy，理论是ActionProxy执行了action。 ActionProxyFactory如何创立ActionProxy? ActionProxyFactory是一个接口，默认的工厂类是DefaultActionProxyFactory，其中的createActionProxy办法如下： public ActionProxy createActionProxy(String namespace, String actionName, String methodName, Map<String, Object> extraContext, boolean executeResult, boolean cleanupContext) { // 创立了一个ActionInvocation实例 ActionInvocation inv = createActionInvocation(extraContext, true); container.inject(inv); // 通过上面的createActionProxy可知ActionProxy中持有了对ActionInvocation的援用 return createActionProxy(inv, namespace, actionName, methodName, executeResult, cleanupContext);} protected ActionInvocation createActionInvocation(Map<String, Object> extraContext, boolean pushAction) { return new DefaultActionInvocation(extraContext, pushAction);} public ActionProxy createActionProxy(ActionInvocation inv, String namespace, String actionName, String methodName, boolean executeResult, boolean cleanupContext) { // 传进去的inv会在prepare的时候用到 DefaultActionProxy proxy = new DefaultActionProxy(inv, namespace, actionName, methodName, executeResult, cleanupContext); container.inject(proxy); // 有一些初始化操作，比方methodname是null的时候就默认执行execute办法 proxy.prepare(); return proxy;}在下面的proxy.prepare 中，除了会对methodname有解决，还有重要的一步是invocation.init(this)，这里的invocation就是new DefaultActionProxy的时候传入的inv，上面看看DefaultActionInvocation中的init会做些什么 ...

转自：码农翻身（微信号：coderising） Http历险记(上) 说到，我来到了Ngnix大厦， 04号长工接待了我， 然后把我转到到Tomcat这里， 遇到了著名的0x6904号线程， 他带着我找了Struts的Filter老大， 然后到二楼找LoginAction , 新的历险开始了… 第三章 警报到二楼一看， 嚯，好家伙，这里有成千上万个通道， 名称全是 ActionProxy, 哪里有什么LoginAciton ? 0x6904说： "奥，我刚刚在线程池里睡觉， 刚起床，犯傻了， 我们想见LoginAction, 得经过特定的ActionProxy通道， 你等等，我去问问Filter老大，我们具体到哪个通道去。 " 我在那儿无聊的等0x6904, 饶有兴趣的看着大家都是从通道的这头进去， 从另外一头出来。 有的快，有的慢。 有个贼头贼脑的家伙刚从一个通道出来， 突然凄厉的警报大声想起来： 注意， 有javascript 攻击。 一群卫兵跑过来把他给按住了， 带头的领导打开这个家伙的包裹， 仔细的检查里边的数据： "报告Filter老大， 这个返回包裹里要把用户输入的数据送回浏览器， 但是这个用户输入的数据包含… 这样的代码，怎么处理，请指示” “按规定消毒吧， 把这些‘<’ ‘>’ 字符做转义操作， 这样发送到浏览器就只是显示，而不会执行了” （码农翻身注： 转义指的是吧 < , > , & 等字符转成 < > & 这样的转义字符） 怪不得Filter老大这么忙， 这么细的事情都管啊。 这时候0x6904气喘吁吁的回来了: “快， 走0xa84d通道” 我说： “刚才那个警报是咋回事， 为什么要把 做转义操作？” "这么说吧， 这些javascript 的脚本不是我们系统产生的， 可能是黑客精心构造的， 通过参数发送到我们这里， 如果我们不消毒， 直接发到用户的浏览器，这些javascript 就有可能在浏览器执行，会把用户的cookie (里边有session id ） 偷走， 然后黑客就可以假装成用户来干坏事了， 例如：把你的钱转走！ " ...

什么是代码生成器？代码生成器就是根据约定俗成的编码规范生成模板代码的工具。例如MVC框架里面的模型(model)、视图(view)、控制器(controller)，对应到实际项目就是controller、service、serviceImpl、dao、daoImpl、model、jsp这一套代码，此时代码生成器就能代替人工重复劳动，自动生成不同业务表对应的一套模板代码。 笔者在网上整理了几个代码生成器，希望能帮助大家提升工作效率，减少重复劳动。 1、力软敏捷框架这个工具致力于敏捷开发，提高工作效率。官网：https://www.learun.cn/Home/Index 2、Magical Coder可以直接在网页上新建项目，建立页面，通过拖拽组件完成页面的布局。这个工具的后端是基于SpringBoot的后台管理系统框架。页面是基于Layui前端框架实现的自由布局器。官网：http://bbs.magicalcoder.com 3、JEEditor一个功能超级强大的代码生成器！！！可以在72小时内完成一个全新项目75%基本功能的快速开发平台！简单三步操作，一键生成功能代码：1.构建ER图对象：用PowerDesign工具创建概念模型表。2.云计算：登录云，自动计算，自动将结果推送到客户端！3.一键生成：点击按钮【一键生成】，功能代码生成完毕。官网：http://www.skycto.com/cms/jsp... 4、IT猿网可以在网页上对验证码、表单HTML、Cron时间表达式等内容进行调试，然后生成对应的Java、HTML代码，直接下载。官网：https://tool.ityuan.com/captcha

现如今有个需求，基于websocket实现浏览器与服务器的通信。由于之前没有使用过websocket，在网上大致搜索了一圈，寻找websocket的集成方案。网上寻找的方案大致如下:1.基于spring的方式实现，加入spring-websocket依赖，加注解，配置相应的拦截器和路径;2.基于springBoot的方式，本质上还是基于spring;3.基于J2EE应用服务器，好像从tomcat7开始有提供websocket支持，直接用@WebsocketEnd 可实现，该注解由servlet包提供; 它们有一个特点，那就是基于servlet实现的(第3种方式尚未求证). 然而，由于种种原因，我需要基于struts2实现，也就是基于Filter实现这个过程，百度了良久，发现的方案是: 在struts2的拦截器中使用元字符开辟一个路径，然后再进行拦截， 尝试未果！ <constant name="struts.action.excludePattern" value="/ws/.*,ws://.*"></constant>最后，采用的spring+注解的方式实现websocket方案。 又由于其他的原因，导致势必要将基于 spirngmvc，也就是servelt的方案转到 struts，也就是Filer去。 因此，经过一番思索加上实践，终于找到了相应的解决方案这里记录一下，以期能够帮助同僚们解决相应的需求： 首先使用堆栈追踪，找到websocket这个servlet执行流程: 堆栈如下: 然后，结合springmvc的执行流程进行分析: 经过分析，我们可以将整个模型逻辑从servelt 搬迁到 相应的Filter上，但是面对诸多的配置，如何平滑的迁移是个问题，我是这样处理的，在mvc这边执行时打上断点，查看相应内存中的变量类型，然后手动构造。原来的代码长这样: 经实践，那些众多的配置以及 @Configuration 用于与springmvc的相应配置，以及这里本地参数的初始化。 因此我完全可以手造一个。 我造的代码如下： 其它的逻辑就直接基于struts即可。经过实践，是可行的，且用起来很顺手，暂未发现其余问题。 应用案例效果图

一直在找这样的项目，准备作为个人项目，找工作时候的谈资：贯穿真个Java知识点的，用到ssh,或者ssm框架，这样就可以让自己对java有一个整体的、清晰的认识。 不管是OA人事管理系统，或者ERP系统，都不能很好地满足我，直到看到这样一个项目，一个很用心的自学网站，分为一个个小的学习模块，有视频教学，还有题目和答案，可以边动手边学习。天猫整站（J2EE、SSH、SSM、SpringBoot等技术实现） 天猫网站实现技术路径及效果

许多消息队列旨在为您的应用程序提供轻量级的发布/订阅消息传输协议。为什么以及合适在您的物联网项目中使用消息队列？考虑温室中的温度传感器，它测量温度。您的应用程序可以在15分钟的时间间隔内（每天月96次）将温度发送到消息队列。而不是处理温室中的数据并始终连接。物联网的消息队列旨在提供轻量级的发布/订阅消息传输。您只需发送数据并在另一项服务中处理数据，而不是保留处理温室数据的应用程序。这需要较少的网络带宽，这可能会限制您的传感器，或者您的传感器通过卫星链路进行通信。消息队列使您的应用程序具有低功耗，发送最小化的数据包，并有效地将信息分发给一个或多个接收器。物联网项目中的消息队列消息队列是一种服务到服务通信的方式。它允许应用程序通过相互发送消息进行通信。消息队列的基本体系结构很简单，有些客户端应用程序可以创建消息并将它们传递到消息队列。其他应用程序/服务从队列中检索消息并处理消息中包含的请求和信息消息可以包含任何类型的信息。例如，它可以获得有关应该从另一个应用程序（可能位于其他位置）开始的进程/任务的消息，或者它可能只是需要处理的数据。物联网和异步消息因特网 应用程序被动反应和异步是一个“必须”。大多数IoT应用程序应该能够处理来自设备的许多连接以及从中过去的所有消息异步消息传递在机器到机器通信中被广泛使用。这以为这发送方不会期望立即相应，并且发送方在等待相应是时不会“阻止”任何内容。异步通信可以实现灵活性，应用程序可以发送消息，然后继续处理其他事情-在同步通信中，它必须等待实时响应。您可以将消息写入队列，然后让相同的业务员逻辑发生，而不是调用Web服务并等待它完成。在您的应用程序需要完成某些操作但不需要立即完成，或者甚至不关心结果的情况下，队列可能很棒。解耦消息队列可用于实现解耦，并有助于保持结构的灵活性。它使得用不同语言编写的两个不同的应用程序连接在一起非常容易。消息队列允许每个组件独立地执行其任务-它允许组件保持完全自治并且彼此不知道，一项服务的更改不应要求更改其他服务。它是分离服务的过程因此它们的功能更加独立。冗余和弹性应用程序有时会崩溃 - 它会发生。这可能是由于超时或您的代码中只有错误影响整个应用程序。消息队列强制可以使接收应用程序确认它已完成任务，并且可以安全地从队列中删除该任务。如果接收应用程序中的任何内容失败，该消息将保留在队列中。当目标程序繁忙或未连接时，消息队列提供临时消息存储。通过打破您的应用程序并按队列分隔不同的组件，您固有地创建了更多的弹性。即使部分后端处理延迟，您的应用程序仍然可以运行。交通高峰许多应用程序的流量激增。门铃应用程序，让您可以从任何地方回答您的门，万圣节期间可能会有交通高峰，而购物应用程序可能会在黑色星期五有交通高峰。通过对数据进行排队，您可以确保最终保留和处理您的数据; 即使这意味着由于高流量峰值，它需要比平常更长的时间。使用RabbitMQ对IoT进行消息队列排队有一些IoT通信协议和标准旨在简化物联网设计。如果您考虑基于队列的解决方案，CloudAMQP会提供两种最流行的开放式消息传递协议；AMQP和MQTT通过RabbitMQ。AMQP是一种安全可靠的协议，开销低，非常适合物联网应用，AMQP是一种比MQTT更先进的协议，更可靠，更好的支持安全性。AMQP还具有灵活路由，持久和持久队列，群集，联合和高可用性队列等功能。缺点是它是一个更冗长的协议-取决于您如何实施您的解决方案。MQTT是为物联网设计的另一种协议。MQTT宣传的物联网优势仅适用于功耗极地的设备。MQTT非常节能 ，它非常注重最小的线路占用空间。由于其简单性，在客户端上实现MQTT所需的工作量比AMQP要少。但是MQTT缺少从服务器到客户端的授权和错误通知，这是一个很大的限制。RabbitMQ是一个消息队列软件，称为消息代理或队列管理器，简单地说，它是一个可以定义队列的软件，应用程序可以连接到队列并将消息传输到队列上。

概念1. 消息队列协议比较三种最常见和最流行的基于TCP/IP的消息传递协议，并提供每种优势的快速总结：AMQP、MQTT和STOMP，RabbitMQ 3.0版本中支持所有这三个协议-我们将使用这些协议作为示例并稍后再回来。AMQPAMQP-高级消息队列协议，旨在作为现有专有消息传递中间件的开放替代品。使用AMQP的两个最重要的原因是可靠性和互操作性。顾名思义，它提供了与消息传递相关的各种功能，包括可靠的排队，基于主题的发布和订阅消息传递，灵活的路由，事务和安全性。AMQP直接以扇出形式，按主题和基于标题交换路由消息。如此丰富的功能集可以实现许多细粒度控制。您可以限制对队列的访问，管理其深度等。消息属性，注释和标题等功能使其非常适合各种企业应用程序。该协议旨在提高许多大型公司的可靠性，这些公司依靠消息传递来集成应用程序并在其组织中移动数据。在RabbitMQ的情况下，有许多不同的语言实现和可用的大样本，使其成为构建大规模，可靠，弹性或群集消息传递基础结构的良好选择。AMQP是一种二进制有线协议，旨在实现不同供应商之间的互操作性。在其他协议失败的情况下，AMQP的采用率很高。摩根大通等公司每天使用它来处理10亿条消息。NASA将其用于星云云计算。Google将其用于复杂的事件处理。以下是一些其他AMQP示例和链接：它被用于世界上最大的生物识别数据库之一印度的Aadhar项目 -拥有12亿个身份。它被用于Ocean Observatories Initiative–一种每天收集8TB数据的架构。amqp.org提供了更多示例和链接。MQTTMQTT（消息队列遥测传输）最初有IBM普及计算团队的开发的，它们与工业领域的合作伙伴共同开发。在过去的几年中，该协议已经转移到开源社区，随着移动应用程序的开始，其受欢迎程度显着增加，并且正在进入标准组的手中MQTT的合集原则和目标比AMQP更简单，，更集中-它提供了发布和订阅消息（没有队列），专门针对资源受限的设备和低带宽、高延迟网络，例如拨号线路和卫星链路。基本上，它可以在嵌入式是系统中有效使用。MQTT对功能更强大的“企业消息传递”代理商的优势之一是其故意低占用空间使其成为当今移动和开发“ 物联网 ”风格应用程序的理想选择。事实上，像Facebook这样的公司正在将它作为移动应用程序的一部分，因为它具有如此低的功耗，并且网络带宽很小。一些基于MQTT的代理支持数千个并发设备连接。它提供三种服务质量：1）火灾和遗忘/不可靠，2）“至少一次”以确保它至少发送一次（但可能被发送超过一次），以及3）“确切地说一旦”。MQTT的优点是简单（只有五种API方法），一个紧凑的二进制数据包有效负载（没有消息属性，压缩标头，比基于文本的HTTP更简洁），它非常适合简单的推送消息传递方案，如温度更新，股票价格代码，油压供应或移动通知。它对于将机器连接在一起非常有用，例如使用MQTT将Arduino设备连接到Web服务。STOMPSTOMP（简单/流式文本导向消息传递协议）是这三种协议中唯一一种基于文本的协议，使其在覆盖范围方面更类似与HTTP。与AMQP一样，STOMP提供带有属性的消息（或帧）标头或帧体。这里的设计原则是创建一些简单且可广泛互操作的东西。例如，可以使用想telnet客户端这样简单的东西连接到STOMP代理。但是，STOMP不处理队列和主题。它使用带有“目标”字符串的SEND语义。代理必须映射到内容理解的内容，例如主题，队列或交换。消费者然后订阅这些目的地。由于规范中没有强制要求这些目的地，因此，不同的经济人可能会支持不同的目的地风格。因此，在代理之间移植代码并不总是直截了当的。但是，STOMP简单而轻便（尽管在线上优点冗长），具有管饭的语言绑定。它还提供了一些事务语义。其中一个最有趣的例子是RabbitMQ Web Stomp，它允许您通过websockets在浏览器中公开消息。这开辟了一些有趣的可能性 - 比如使用所有类型的信息实时更新浏览器，移动应用程序或机器。2. 消息队列什么是消息队列？消息队列是一种异步的服务间通信方式，使用与无服务和微服务架构。消息在被处理和删除之前一直存储在队列上。每条消息仅可被一直为用户处理一次。消息队列可被用于分离重量级处理、缓存或批处理工作以及缓解高峰期工作负载。在现代云架构中，应用程序被分解为多个规模较小且更易于开发、部署和维护的独立构建模块。消息队列可为这些分布式应用程序提供通信和协调。消息队列可以显著简化分离应用程序的编码，同时提高性能、可靠性和可扩展性。借助消息队列，系统的不同部分可相互通信并异步执行处理操作。消息队列提供一个临时存储消息的轻量级缓存区，以及允许软件组件连接到队列以发送接受消息的的终端节点。这些消息通常较小，可以是请求、恢复、错误消息或明文消息等。要发送消息时，一个名为“创建器”的组件将消息添加到队列。消息将存储在队列中，直至名为“处理器”的另一组件检索该消息并执行相关操作。许多创建器和处理器都可以使用队列，但一条信息只能有一盒处理器处理一次。因此，这种消息收发模式通常称为一对一或点对点通信。如果消息需要由多个处理器进行处理，可采用扇出设计模式将消息队列与发布/订阅消息收发结合起来。3. 消息中间件RabbitMQKafkaRocketMQQpidArtemisNSQZeroMQ4. 发布/订阅消息收发发布/订阅消息收发是一种异步的服务间通信方式，适用于无服务和微服务架构。在发布/订阅模式下，发布到主题的任何的任何消息都会立即被主题的所有订阅者接受。发布/订阅消息收发可用于启用事件驱动架构，或分离应用程序，以提高性能、可靠性和可扩展性。发布/订阅消息收发基础知识在现代云架构中，应用程序被分解为多个规模较小且易于开发、部署和维护的独立构建块。发布/订阅消息收发可以为这些分布式应用程序提供及时事件通知。发布/订阅模式让消息能够异步广播到系统中的不同部分。消息主题与消息队列类似，可以提供一个轻量型机制来广播异步事件通知，还可以提供能让软件组件连接主题以便发送和接受消息的终端节点。在广播消息时，一个叫做“发布者”的组件会将消息推送到主题。与在消息被检索前批量处理消息的消息队列不同的是，消息主题无需或使用极少消息队列即可传输消息，并将消息立即推送给所有订阅者。订阅该主题的所有组件都会收到广播的每一条消息，除非订阅着设置了消息筛选策略。消息主题的订阅着通常执行不同的功能，并可以同时对消息执行不同的操作。发布者无需知道谁在使用广播的消息而订阅着也无需知道消息来自哪里。这种消息收发模式与消息队列稍有不同，在消息队列中，发送消息的组件通常知道发送目的地。技术选择毫不奇怪，考虑到基本消息传递对数据驱动的应用程序的影响，有许多技术支持某种形式的消息队列，发布 - 订阅消息传递或两者兼而有之。技术，如Apache的ActiveMQ的，亚马逊SQS，IBM的WebSphere MQ，RabbitMQ的，和RocketMQ最初设计主要是为消息排队的用例。Apache Kafka和Google Cloud Pub / Sub等其他技术主要用于支持发布 - 订阅用例。其他通常较新的解决方案，如 Apache Pulsar， 支持 消息队列和pub-sub消息传递。RabbitMQ、Kafka和ActiveMQ都是用于提供异步通信和解耦进程（分离消息的发送者和接受者）的消息传递技术。它们被称为消息队列，消息代理或消息传递工具。RabbitMQ、Kafka和ActiveMQ都具有相同的基本用途。但可以以不同的方式完成工作。Kafka始终高吞吐量的分布式消息传递系统。RabbitMQ是基于AMQP的可靠消息代理。ActiveMQ和Kafka都是Apache产品，都是用Java编写的；RabbitMQ是用Erlang编写的。https://stackshare.io/stackup…