Spring Boot Executable JAR: Fat JAR 与 JarLauncher

背景 Spring Boot 把应用打成单个可执行 JAR,java -jar app.jar 即可启动内嵌 Tomcat(或 Jetty/Undertow)与全部依赖。这与传统「WAR 部署到外部 Tomcat、classpath 由容器管理」不同,也不同于 Maven jar-with-dependencies 那种把依赖 class 解压合并进一个 jar 的做法。 本文说明 Spring Boot 可执行 JAR 的内部布局、JarLauncher 如何启动应用,以及 repackage / bootJar 如何生成该产物。容器镜像、分层 JAR、Buildpack 等部署话题见 Spring Boot Container Packaging;框架层面的「内嵌服务器 + 可执行 JAR」见 Spring Boot。 Thin jar 与 fat jar Fat jar、uber jar、executable jar 在 Spring Boot 语境下指同一件事:一个「全包」可执行 jar。Fat jar 与 uber jar 只是不同叫法(uber 来自德语 über,意为「之上 / 全部」);Spring 官方文档更常写 executable jar。 与 Maven/Gradle 默认打出的普通 jar(常称 thin jar / plain jar)对比如下: ...

Created 24246-06-24 · Updated 27276-06-27 · 5 min · 973 words · -

Spring WebFlux: 响应式 Web 框架

Spring WebFlux 是 Spring 5(2017)引入的响应式 Web 框架,与基于 Servlet 的 Spring MVC 并列。Boot 总览见 Spring Boot;若只需提升并发能力而不改编程模型,可先看 Java Virtual Threads。 解决的问题 传统 Spring MVC 基于 Servlet 模型,每个请求占用一个线程,调用数据库或外部 API 时线程阻塞等待: 请求进来 → 分配线程 → 调用数据库(等待 100ms,线程阻塞)→ 调用外部 API(等待 200ms,线程阻塞)→ 返回 Tomcat 默认线程池约 200 个线程,高并发下线程池耗尽,后续请求排队。 Spring WebFlux 引入响应式编程模型,底层使用 Netty(非 Servlet 容器),少量线程处理大量并发: 请求进来 → 少量线程(CPU 核数)→ 发起数据库查询(注册回调,线程立刻去处理其他请求)→ 数据返回时触发回调继续处理 编程模型 WebFlux 使用 Reactor 库的 Mono<T>(0 或 1 个异步结果)和 Flux<T>(0 到 N 个异步结果): // Spring MVC(同步阻塞) @GetMapping("/users/{id}") public User getUser(@PathVariable Long id) { return userService.findById(id); // blocks on DB } // Spring WebFlux(异步非阻塞) @GetMapping("/users/{id}") public Mono<User> getUser(@PathVariable Long id) { return userService.findById(id); // returns a deferred result } WebFlux 的局限 编程模型与传统命令式完全不同,调试困难,学习成本高 需要支持响应式的驱动(R2DBC 替代 JDBC),不是所有库都有响应式版本 Java 21 虚拟线程的出现大幅削弱了 WebFlux 在普通业务系统里的核心优势(见 Java Virtual Threads) 何时仍选 WebFlux SSE 实时推送 需要背压控制(消费者告知生产者降速)的流式处理 已有 WebFlux 项目:继续用即可,不必为并发改回 MVC Java 网络层全景 主流 Java Web 栈最终归为两大谱系: ...

Created 26266-06-26 · Updated 27276-06-27 · 2 min · 283 words · wiloon

Spring

Spring 通常指 Spring Framework——一个以 IoC 容器为核心的 Java 企业应用基础框架。它不是专门为 Web 而生的;Web 处理只是其众多模块之一。要理解 Spring MVC、Spring Boot 在生态里的位置,需要先弄清 Spring Framework 本身解决什么问题、各模块如何分工,以及它在 J2EE 时代是如何演进来的。 Spring Framework 是什么 Spring Framework 提供: IoC 容器:创建对象、装配依赖、管理生命周期(详见 Spring IoC,依赖注入) AOP:横切关注点(日志、事务、安全等)与业务代码分离(详见 aop) 数据访问与事务:JDBC 抽象、@Transactional、与 Hibernate / JPA / MyBatis 集成 Web 层:Spring MVC(详见 Spring MVC) 集成能力:消息、邮件、调度任务等 典型分层关系: Spring Framework(基础框架) ├── Core(IoC、AOP、事件、资源抽象) ├── Data Access(JDBC、ORM 集成、事务) ├── Spring MVC(Web 层:DispatcherServlet、Controller) ├── Integration(JMS、邮件等) └── 以及 Security、Batch 等扩展项目 Spring Boot(2014,构建在 Spring Framework 之上) └── 自动配置 + Starter,简化上述模块的装配与部署(详见 [Spring Boot](./spring-boot.md)) Spring 与 Spring MVC 的关系 Spring MVC 是 Spring Framework 里的 Web 模块,不是与 Spring 平级的独立框架。 ...

Created 24246-06-24 · Updated 26266-06-26 · 6 min · 1207 words · -

Spring Boot 3.x Migration: 关键特性与约束

Spring Boot 3.0(2022 年底发布)底层依赖 Spring Framework 6.x。本文汇总从 2.x 升级到 3.x 时最常见的破坏性变更与约束。框架总览见 Spring Boot。 Spring Boot 与 Spring Framework 版本对应 Spring Boot Spring Framework 3.0.x 6.0.x 3.2.x 6.1.x 3.3.x / 3.4.x 6.1.x / 6.2.x 3.5.x 6.2.x 1. Java 版本要求 Spring Boot 3.x 最低要求 Java 17。 2. javax → jakarta 命名空间迁移(最大变更) Java EE 已捐赠给 Eclipse 基金会,品牌更名为 Jakarta EE,所有包名从 javax.* 改为 jakarta.*。这是代码层面影响最广的变更,几乎所有用到 Servlet、JPA、Bean Validation 的代码都要修改: 旧包名(javax) 新包名(jakarta) javax.servlet.* jakarta.servlet.* javax.persistence.* jakarta.persistence.* javax.validation.* jakarta.validation.* javax.transaction.* jakarta.transaction.* javax.annotation.* jakarta.annotation.* import jakarta.servlet.http.HttpServletRequest; import jakarta.persistence.Entity; 3. Spring Security 6.x:WebSecurityConfigurerAdapter 彻底移除 WebSecurityConfigurerAdapter 已彻底移除,必须改为注册 SecurityFilterChain Bean,详见 Spring Security。 ...

Created 26266-06-26 · Updated 26266-06-26 · 2 min · 214 words · wiloon

Spring Boot Container Packaging: Fat JAR、分层 JAR 与 Buildpacks

背景 Spring Boot REST API 打成 jar 之后,放进容器常见有三层递进:先有一个能跑的 fat jar,再用分层 JAR 优化 Docker 缓存,最后用 Cloud Native Buildpacks 一键出镜像;若还要缩小运行时,可在 Buildpack 上显式开启 jlink 裁剪 JRE。fat jar 布局与 JarLauncher 见专文 Spring Boot Executable JAR。 Spring Framework 本身几乎不讲容器镜像;相关说明集中在 Spring Boot Reference 的 Packaging → Container Images。本文把分层 JAR、bootBuildImage、Paketo jlink 串成一条阅读路径,并附上官方文档索引。GraalVM Native Image 是另一条路线,见 GraalVM Native Image 简介。 三条路径总览 flowchart TB subgraph build [构建] SRC[源码 mvn package / bootJar] FAT[Fat JAR 可执行 uber jar] LAY[分层 JAR 含 layers.idx] end subgraph deploy [容器化] D1[简单 DockerfileCOPY jar + java -jar] D2[分层 Dockerfilejarmode extract --layers] BP[bootBuildImage / build-imagePaketo Buildpacks] end subgraph runtime [运行时 JVM] JRE[完整 JRE] JLINK[jlink 精简 JREBP_JVM_JLINK_ENABLED] end SRC --> FAT FAT --> LAY FAT --> D1 LAY --> D2 LAY --> BP D1 --> JRE D2 --> JRE BP --> JRE BP -.->|可选| JLINK 路径 典型产物 主要收益 复杂度 Fat jar + 简单镜像 单层 app.jar + JRE 基础镜像 上手最快 低 分层 JAR + Dockerfile 多 COPY 层 + JRE 推送镜像时依赖层可缓存 中 Buildpack(bootBuildImage) OCI 镜像,自动检测 jar 零 Dockerfile、与 Paketo 生态一致 低~中 Buildpack + jlink 同上,运行时 JRE 更小 缩小镜像体积 中(需调 env) 分层 JAR 分层 JAR 在 fat jar 布局不变的前提下,额外写入 BOOT-INF/layers.idx,声明哪些路径属于哪一层、层的写入顺序。Spring Boot 2.3 起默认开启;Maven repackage / Gradle bootJar 的 layered 无需额外配置即可得到。 ...

Created 21216-06-21 · Updated 24246-06-24 · 5 min · 1027 words · -

Spring Boot DevTools

背景 开发 Spring Boot 时,spring-boot-devtools 提供 快速重启 与 静态资源热刷新,常被误认为「和 IDE HotSwap 一样改 Java 就能生效」。本文说明它实际做什么,并与 开发期热替换、JPDA 区分。 Spring Boot 总览见 Spring Boot。 依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency> 仅在开发 classpath 使用;生产打包应排除(optional + 不打进 fat jar 的常见做法)。 两个 ClassLoader(Restart) DevTools 默认启用 Restart: ClassLoader 加载内容 变更时 base 第三方依赖(spring-boot-starter-* 等) 一般不 reload restart 你的 target/classes 业务代码 监控到变更后 快速重启 应用上下文 「快速重启」不是 HotSpot 的 类热替换:而是 停掉当前 Spring 上下文再拉起,但 base ClassLoader 保留,比冷启动整个 JVM 快。 因此: 改 业务 Java 类 → 触发 restart(仍是一次上下文重建,不是 JPDA 改方法体) 改 静态资源(src/main/resources 下 html/css 等)→ LiveReload 通知浏览器刷新,无需重启 JVM 与 HotSwap / BTrace 的对比 机制 层级 典型场景 DevTools Restart Spring 上下文 + 双 ClassLoader 本地改代码后几秒内重新跑 Bean IDE HotSwap JVM + JPDA / 有限 redefine Debug 下改 方法体 DCEVM + HotSwapAgent 增强 HotSpot + javaagent 开发机放宽 redefine、重载 Spring 配置 BTrace attach Attach + ASM 已运行 进程观测,非开发热更 DevTools 不 使用 Attach API 给业务类插探针;也 不 替代 mvn spring-boot:run 外的生产部署。 ...

Created 31316-05-31 · Updated 31316-05-31 · 1 min · 189 words · -

spring basic

spring basic @RestController @RestController 是 @Controller 与 @ResponseBody 的组合注解,用于编写 RESTful API:控制器方法的返回值会直接写入 HTTP 响应体(通常是 JSON),而不是交给视图解析器去渲染页面。 @RestController @RequestMapping("/api/comments") public class CommentController { @GetMapping("/{id}") public Comment get(@PathVariable long id) { return commentService.findById(id); } } 上例中,Comment 对象会被 HttpMessageConverter(如 Jackson)序列化为 JSON 返回给客户端。 适用场景: 前后端分离:Vue、React、移动端等通过 HTTP 调用后端接口 微服务之间的 HTTP 调用 任何「请求数据 → 返回 JSON/XML」的 API 不适用场景: 传统的服务端渲染 Web 应用(JSP、Thymeleaf 等):这类应用需要 @Controller 返回视图名或 ModelAndView,由视图解析器渲染 HTML 页面 @Controller public class PageController { @GetMapping("/home") public String home(Model model) { model.addAttribute("title", "Home"); return "home"; // 解析为 home.jsp 或 templates/home.html } } 若把 JSP/Thymeleaf 页面控制器写成 @RestController,返回值会被当作响应体内容(例如字符串 "home" 会原样输出),而不会走视图解析,页面无法正常渲染。 ...

Created 5056-01-05 · Updated 20206-05-20 · 2 min · 352 words · -

AOP

AOP(Aspect-Oriented Programming,面向切面编程)是对 OOP 的补充,用于将横切关注点(cross-cutting concerns)从业务逻辑中分离出来,集中管理。典型横切关注点包括:日志记录、事务管理、权限校验、性能监控、缓存、同步等——这些逻辑如果分散在每个方法里,既冗余又难以维护。 AOP 实际是 GoF 设计模式的延续,设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,AOP 可以说也是这种目标的一种实现。 AOP 解决了什么问题 在没有 AOP 的情况下,每个业务方法都要亲自处理横切逻辑: // 没有 AOP:每个方法都要重复写日志、事务、权限检查 public User findById(Long id) { log.info("开始查询 user={}", id); // 日志 checkPermission("user:read"); // 权限 Transaction tx = db.beginTransaction(); // 事务 try { User user = db.query(id); // 真正的业务逻辑 tx.commit(); return user; } catch (Exception e) { tx.rollback(); throw e; } finally { log.info("查询结束"); // 日志 } } 这带来三个问题: ...

Created 7076-01-07 · Updated 12126-05-12 · 4 min · 775 words · -

Front Controller Pattern

概述 Front Controller Pattern(前端控制器模式)来自 Martin Fowler 的《企业应用架构模式》(Patterns of Enterprise Application Architecture,2002),属于 Web 层架构模式,不是 GoF 23 种设计模式的一部分。 详见 企业应用架构模式。 解决的问题 在原始 Servlet 时代,每个 URL 对应一个独立的 Servlet 类,这是 Page Controller 模式: /users → UsersServlet /orders → OrdersServlet /products → ProductsServlet 每个 Servlet 都要自己处理身份验证、日志记录、权限检查,代码大量重复。随着 URL 增多,web.xml 里的注册条目也膨胀。 Front Controller 的解法是单一入口: 所有请求 → FrontController(统一处理横切关注点)→ Dispatcher → 具体处理器 三个角色 Front Controller:所有请求的唯一入口,集中处理身份验证、权限验证、日志追踪等横切关注点 Dispatcher:将请求路由到对应的具体处理器(View/Handler) View / Handler:真正处理业务逻辑的模块 Spring MVC 中的实现 Spring MVC 的 DispatcherServlet 是 Front Controller 模式的标准实现: ...

Created 12126-02-12 · Updated 11116-05-11 · 2 min · 234 words · -

BeanFactory, ApplicationContext

BeanFactory, ApplicationContext http://blog.csdn.net/liaomin416100569/article/details/4924183 org.springframework.beans.factory.BeanFactory 是Spring IoC容器的实际代表者, IoC容器负责容纳此前所描述的bean,并对bean进行管理。 在Spring中,BeanFactory是IoC容器的核心接口。 它的职责包括: 实例化、定位、配置 应用程序中的对象及建立这些对象间的依赖。 Spring为我们提供了许多易用的BeanFactory实现, XmlBeanFactory就是最常用的一个。 该实现将以XML方式描述组成应用的对象 以 及对象间的依赖关系。XmlBeanFactory类将获取此XML配 置元数据,并用它来构建一个完 全可配置的系统或应用。 BeanFactory 提供的高级配置机制,使得管理各种对象成为可能。 ApplicationContext 是BeanFactory的扩展,功能得到了进一步增强,比如更易 与Spring AOP集成、资源处理 (国际化处理)、事件传递及各种不同应用层的context实现 (如针对web应用的WebApplicationContext)。 简而言之,BeanFactory提供了配制框架及基本功能,而 ApplicationContext 则增加了 更多支持企业核心内容的功能。 ApplicationContext完全由BeanFactory扩展而来, 因而BeanFactory所具备的能力和行为也适用于ApplicationContext。 使用getBean(String) 方法就可以取得bean的实例;BeanFactory 提供的方法极其简单。 BeanFactory接口提供 了非常多的方法,但是对于我们的应用来说,最好永远不要调用它们,当然也包括 使用getBean(String)方法,这样可以避免我们对 Spring API的依赖。 BeanFactory 同时也不具备 编译spring配置文件的功能 在容器初始化时 如果applicationContext出现错误时 BeanFactory并不能及时察觉,必须等待第一次获取bean的实例时才能抛出异常 比如实例化 BeanFactory Resource res = new FileSystemResource(“applicationContext.xml”); BeanFactory factory = new XmlBeanFactory(res); Resource resClasspath = new ClassPathResource(“applicationContext.xml.xml”); BeanFactory factory2 = new XmlBeanFactory(resClasspath); 获得BeanFactory实例时 不能检查错误 User u=(User)u.getBean(“user”); ...

Created 26266-01-26 · Updated 26266-01-26 · 1 min · 79 words · -

spring mvc + mybatis

spring mvc + mybatis 维护记录 时间 修改内容 原因 2026-06-24 移至 language/java/spring/spring-mvc-mybatis.md 与 Spring 专题文章同目录归类

Created 6066-05-06 · Updated 6066-05-06 · 1 min · 14 words · -

spring junit

spring junit 一.首先讲下注解,autowire 与 resource的区别 @Autowired是按类型装配依赖对象,默认情况下,要求依赖对象必须存在,若允许null值,可以设置它的required属性为false。如果想使用按名称装配,可以结合@Qualifier注解一起使用。如: @Autowired @Qualifier(“xmlBean1”) private XMLBean xmlBean; @Resource和@Autowired一样,也可以标注在字段或属性的setter方法上,但它默认是按名称装配。名称可以通过@Resource的name属性指定,如果没有指定name属性,当注解标注在字段上,即默认取字段的名称作为bean名称寻找对象,当注解标注在属性的setter方法上,即默认取属性名作为bean名称寻找依赖对象。当没有使用name属性时,如果按照字段名找不到bean,就会转而使用按类型装配的方式进行查找;但当使用了name属性,只能按照指定的name查找bean,当找不到相应的bean时,就会抛异常。 @Resource(name=“xmlBeanx”) private XMLBean xmlBean;//用于字段上 二.讲解spring测试套件的好处: 在开发基于Spring的应用时,如果你还直接使用Junit进行单元测试,那你就错过了Spring为我们所提供的饕餮大餐了。使用Junit直接进行单元测试有以下四大不足: 导致多次Spring容器初始化问题 根据JUnit测试方法的调用流程,每执行一个测试方法都会创建一个测试用例的实例并调用setUp()方法。由于一般情况下,我们在setUp()方法中初始化Spring容器,这意味着如果测试用例有多少个测试方法,Spring容器就会被重复初始化多次。虽然初始化Spring容器的速度并不会太慢,但由于可能会在Spring容器初始化时执行加载Hibernate映射文件等耗时的操作,如果每执行一个测试方法都必须重复初始化Spring容器,则对测试性能的影响是不容忽视的; -->使用Spring测试套件,Spring容器只会初始化一次! 需要使用硬编码方式手工获取Bean 在测试用例类中我们需要通过ctx.getBean()方法从Spirng容器中获取需要测试的目标Bean,并且还要进行强制类型转换的造型操作。这种乏味的操作迷漫在测试用例的代码中,让人觉得烦琐不堪; -->使用Spring测试套件,测试用例类中的属性会被自动填充Spring容器的对应Bean ,无须在手工设置Bean! 数据库现场容易遭受破坏 测试方法对数据库的更改操作会持久化到数据库中。虽然是针对开发数据库进行操作,但如果数据操作的影响是持久的,可能会影响到后面的测试行为。举个例子,用户在测试方法中插入一条ID为1的User记录,第一次运行不会有问题,第二次运行时,就会因为主键冲突而导致测试用例失败。所以应该既能够完成功能逻辑检查,又能够在测试完成后恢复现场,不会留下"后遗症"; -->使用Spring测试套件,Spring会在你验证后,自动回滚对数据库的操作,保证数据库的现场不被破坏,因此重复测试不会发生问题! 不方便对数据操作正确性进行检查 假如我们向登录日志表插入了一条成功登录日志,可是我们却没有对t_login_log表中是否确实添加了一条记录进行检查。一般情况下,我们可能是打开数据库,肉眼观察是否插入了相应的记录,但这严重违背了自动测试的原则。试想在测试包括成千上万个数据操作行为的程序时,如何用肉眼进行检查? -->只要你继承Spring的测试套件的用例类,你就可以通过jdbcTemplate在同一事务中访问数据库,查询数据的变化,验证操作的正确性! Spring提供了一套扩展于Junit测试用例的测试套件,使用这套测试套件完全解决了以上四个问题,让我们测试Spring的应用更加方便。现在我的项目中已经完成摒弃Junit,而采用Spring的测试套件,确实带来了很大的便利。严重推荐Springer使用这个测试套件。这个测试套件主要由org.springframework.test包下的若干类组成,使用简单快捷,方便上手。 ** 最后讲spring 的 测试套件:** 1.显示基类,其实就是用来加载配置文件的 @RunWith(SpringJUnit4ClassRunner.class) //使用junit4进行测试@ContextConfiguration({"/app*.xml","/spring/app*.xml","/spring/service/app*.xml"}) //加载配置文件 public class BaseJunit4Test { } 接着是我们自己的测试类 public class UserAssignServiceTest extends BaseJunit4Test{ @Resource //自动注入,默认按名称 private UserAssignService userAssignService; @Test //标明是测试方法 @Transactional //标明此方法需使用事务 @Rollback(false) //标明使用完此方法后事务不回滚,true时为回滚 public void testInsertUserAssign() { for(int i=0;i<10;i++){ UserAssign u=new UserAssign(); u.setAmount("7"); u.setCity(2); u.setProvince(1); u.setCompany("宜信"); u.setCreate_date(DateUtil.getCurrentTimeSecond()); u.setCreator(0); u.setEmail("1133@163.com"); u.setOper_date(DateUtil.getCurrentTimeSecond()); u.setPosition("工人"); u.setOperator(0); u.setQudao("2"); u.setUsername("张"+i); userAssignService.insertUserAssign(u); Assert.assertNotNull(u.getId()); } } }

Created 24246-02-24 · Updated 24246-02-24 · 1 min · 88 words · -

spring MVC 返回JSON数据(Spring3.0 MVC+Jackson+AJAX)

spring MVC 返回JSON数据 (Spring3.0 MVC+Jackson+AJAX) 本文本的框架为:SpringMVC 3.2.3 \ jackson 1.9.2 传统的返回JSON格式的AJAX,用的方法一般是: 在后台先把数据(Object)封装成JSON数据,再用HttpServletResponse返回。 本示例中,SpringMVC可直接支持JSON格式数据的返回。具体如下。 1、JAR包: SPRINGMVC包需的包,另外还需JACKSON的两个包。 jackson-core-asl-1.9.2.jar jackson-mapper-asl-1.9.2.jar 2、spring-servlet.xml中加入: Java代码 <img alt="收藏代码" src="http://angelbill3.iteye.com/images/icon_star.png" /> <!- 返回JSON模版 -> <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter" > <property name="messageConverters"> <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter" /> </list> </property> </bean> 我们在SPRING的配置中加入了一个新的适配器: AnnotationMethodHandlerAdapter,通过这个适配器,我们配置了一个属性,messageConverters,其中mappingJacksonHttpMessageConverter这个Bean,它就是用来处理json数据转换的。 注: 我的项目中没有乱码现象,这样配即可,若有乱码现象,可以在MappingJacksonHttpMessageConverter的BEAN中配置supportedMediaTypes属性,是用于解决返回的乱码问题。 3、Controller中的使用 Java代码 <img alt="收藏代码" src="http://angelbill3.iteye.com/images/icon_star.png" /> @Controller public class SelectController { @Resource private TypeService typeService; @RequestMapping("/type") @ResponseBody public Object type(){ List<Type> typelist = this.typeService.getTypeByParentid(Const.TYPE_DAILY); return typelist; } } 在SpringMVC中可以在Controller的某个方法上加**@ResponseBody**注解,表示该方法的返回结果直接写入HTTP response body中。 ...

Created 21216-02-21 · Updated 21216-02-21 · 1 min · 139 words · -

ModelAndView

ModelAndView http://itroop.iteye.com/blog/263845 的构造方法有7个。但是它们都是相通的。这里使用无参构造函数来举例说明如何构造ModelAndView 实例。 ModelAndView类别就如其名称所示,是代表了MVC Web程序中Model与View的对象,不过它只是方便您一次返回这两个对象的holder,Model与View两者仍是分离的概念。 最简单的ModelAndView是持有View的名称返回,之后View名称被view resolver,也就是实作org.springframework.web.servlet.View接口的实例解析,例如 InternalResourceView或JstlView等等: ModelAndView(String viewName) 如果您要返回Model对象,则可以使用Map来收集这些Model对象,然后设定给ModelAndView,使用下面这个版本的ModelAndView: ModelAndView(String viewName, Map model) Map对象中设定好key与value值,之后可以在视图中取出,如果您只是要返回一个Model对象,则可以使用下面这个ModelAndView版本: ModelAndView(String viewName, String modelName, Object modelObject) 藉由modelName,您可以在视图中取出Model并显示。 ModelAndView类别提供实作View接口的对象来作View的参数: ModelAndView(View view) ModelAndView(View view, Map model) ModelAndView(View view, String modelName, Object modelObject) 一个例子是org.springframework.web.servlet.view.RedirectView,ModelAndView预设是使 用forward来转发请求结果至视图,使用RedirectView的话,则会使用redirect将请求重导至视图,例如: … public ModelAndView handleRequest(….) … { …. return new ModelAndView(new RedirectView(this.getViewPage())); } …. 在这边,viewPage的地址是从服务器网页根目录开始指定,而不是Web应用程序的根目录,所以您的getViewPage()传回的地址必须像是 /springapp/pages/index.htm这样的地址,其中springapp是您的Web应用程序目录。 使用forward的话,网址列上并不会出现被转发的目标地址,而且forward是在Web应用程序之内进行,可以访问Web应用程序的隐藏目录,像是WEB-INF,然而forward只能在Web应用程序中进行,不能指定至其它的Web应用程序地址。 使用redirect的话,是要求客户端浏览器重新发出一个指定的请求地址,因此网址列上会出现被重导的目录地址,重导的请求是由浏览器发出,所以不能 访问Web应用程序中的隐藏目录,像是WEB-INF,然而重导是重新要求一个网页,所以可以指定至其它的Web应用程序地址。 DispatcherServlet会根据传回的ModelAndView来解析View名称,并处理给予的Model。View名称的解析是委托给实 作org.springframework.web.servlet.ViewResolver接口的实例,ViewResolver接口定义如下: public interface ViewResolver { public view resolveViewName(String, Locale locale) throws ServletException; } ViewResolver的一个实例是InternalResourceViewResolver,名称解析完之后,实际的View绘制与Model转 换处理是交给实作org.springframework.web.servlet.View的实例,View接口如下: public interface View { ...

Created 9096-01-09 · Updated 9096-01-09 · 1 min · 153 words · -

spring MVC json

spring MVC json spring mvc 返回json格式数据的方式 http://blog.csdn.net/skmbw/article/details/12263253 <dependency> <groupId>org.codehaus.jackson</groupId> jackson-core-lgpl</artifactId> <version>1.9.11</version> </dependency> <dependency> <groupId>org.codehaus.jackson</groupId> jackson-mapper-lgpl</artifactId> <version>1.9.11</version> </dependency> 维护记录 时间 修改内容 原因 2026-06-24 移至 language/java/spring/spring-mvc-json.md 与 Spring 专题文章同目录归类

Created 2026-02-02 · Updated 2026-02-02 · 1 min · 27 words · -

Ed25519

Ed25519 http://ed25519.cr.yp.to/Ed25519 它是一个数字签名算法,签名和验证的性能都极高, 一个4核2.4GHz 的 Westmere cpu,每秒可以验证 71000 个签名,安全性极高,等价于RSA约3000-bit。签名过程不依赖随机数生成器,不依赖hash函数的防碰撞性,没有时间通道攻击的问题,并且签名很小,只有64字节,公钥也很小,只有32字节。 部署情况http://ianix.com/pub/ed25519-deployment.html 最近看到恒星(Stellar)网络使用了Ed25519算法作为签名算法,有点兴趣,无奈资料太少,其算法网站也比较简陋,结合找到的资料和网站介绍,粗略看了看,25519这个算法很有特点,相比传统椭圆曲线算法有较大优势,今天简单介绍给大家 Curve25519/Ed25519/X25519 是著名密码学家 Daniel J. Bernstein 在 2006 年独立设计的椭圆曲线加密 /签名 /密钥交换算法,和现有的任何椭圆曲线算法都完全独立,其中Ed25519用于签名,可在区块链中进行签名,Stellar就是使用了Ed25519作为签名算法的 Daniel J. Bernstein 是世界著名的密码学家,他在大学曾经开设过一门 UNIX 系统安全的课程给学生,结果一学期下来,发现了 UNIX 程序中的 91 个安全漏洞; 他早年在美国依然禁止出口加密算法时,曾因为把自己设计的加密算法发布到网上遭到了美国政府的起诉,他本人抗争六年,最后美国政府撤销所有指控,目前另一个非常火的高性能安全流密码 ChaCha20 也是出自 Bernstein 之手 25519 系列曲线自 2006 年发表以来,除了学术界无人问津, 2013 年爱德华·斯诺登曝光棱镜计划后,该算法突然大火。大量软件,如 OpenSSH 都迅速增加了对 25519 系列的支持,如今 25519 已经是大势所趋,可疑的 NIST 曲线迟早要退出椭圆曲线的历史舞台,目前, RFC 增加了 SSL/TLS 对 X25519 密钥交换协议的支持,而新版 OpenSSL 1.1 也加入支持,是摆脱老大哥的第一步,下一步是将 Ed25519 做为可选的 TLS 证书签名算法,彻底摆脱 NIST 。 根据其网站介绍,Ed25519 算法具有以下优势: 完全开放设计,算法各参数的选择直截了当,非常明确,没有任何可疑之处,相比之下,目前广泛使用的椭圆曲线是 NIST 系列标准,方程的系数是使用来历不明的随机种子 c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 生成的,至于这个种子的来历没有资料介绍; ...

Created 23236-01-23 · Updated 23236-01-23 · 4 min · 836 words · -