Spring系中常见注解用法说明

@PathVariable与@RequestParm在spring mvc中,有@requestparm, @requestbody和@pathvariable 三种注解来获得浏览器端的参数,其中@requestparm是取自url中“?”之后的a=b&c=d,@requestbody 来自

@PathVariable与@RequestParm

在spring mvc中,有@requestparm, @requestbody和@pathvariable 三种注解来获得浏览器端的参数,其中@requestparm是取自url中“?”之后的a=b&c=d,@requestbody 来自于请求体,而@pathvariable 则是从网址中取得参数;

感谢评论区@comeoon的订正,浏览器的get/put/delete/post方法都可以使用上述参数,但是由于浏览器get方法不能提供body,所以RequestBody实际获取的是一个map,参数来自于url中“?”之后的参数(实际上是request parameters)

假设代码如下:

@Requestmapping(value="/{category}/{brand}/{id},method=RequestMethod.POST)
public void getbyid(@PathVariable("category") String category
                    @PathVariable("brand") String brand
                    @PathVariable("id") String id){
	//具体代码略
}

@Controller与@RestController

@restcontroller为@controller和@responsebody的结合。在@controller注解中,返回的是字符串,或者是字符串匹配的模板名称,即直接渲染视图,与html页面配合使用的,在这种情况下,前后端的配合要求比较高,java后端的代码要结合html的情况进行渲染,使用model对象(或者modelandview)将user的属性渲染到页面。

@Controller
@RequestMapping(method = RequestMethod.GET, value = "/")
public String getuser(Model model) throws IOException {

    model.addAttribute("name",bob);
    model.addAttribute("sex",boy);
    return "user";
}

前端取数据:

<html xmlns:th="http://www.thymeleaf.org">
<body>
    <div>
        <p>"${name}"</p>
        <p>"${sex}"</p>
    </div>
</body>
</html>

而在@restcontroller中,返回的应该是一个对象,即return一个user对象,这时,在没有页面的情况下,也能看到返回的是一个user对象对应的json字符串,而前端的作用是利用返回的json进行解析渲染页面,java后端的代码比较自由。

@RestController
@RequestMapping(method = RequestMethod.GET, value = "/")
public User getuser( ) throws IOException {
    User bob=new User();
    bob.setName("bob");
    bob.setSex("boy");
    return bob;
}

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd