SpringWeb

SpringWeb

之前javaEE开发中,web层使用的原生的Servlet, 弊端: 类中只提供doGet/doPost方法, 接收参数很麻烦 ,响应数据也很麻烦(java对象转为json格式)

spring中的web模块就可以解决以上存在的问题

SpringWEB 组件

前端控制器:DispatcherServlet(不需要程序员开发),由框架提供,在web.xml 中配置。作用:统一处理请求和响应,整个流程控制的中心,由它调用其它组件处理用户的请求.处理器映射器:HandlerMapping(不需要程序员开发),由框架提供。作用:根据请求的 url 查找 Handler(处理器/Controller)处理器适配器:HandlerAdapter(不需要程序员开发),由框架提供。作用:按照特定规则(HandlerAdapter 要求的规则)去执行 Handler。处理器:Handler(也称之为 Controller,需要工程师开发)。注意:编写 Handler 时按照 HandlerAdapter 的要求去做,这样适配器才可以去正确执行 Handler。作用:接受用户请求信息,调用业务方法处理请求,也称之为后端控制器。

搭建 SpringWeb

导包

<dependency><groupId>org.springframework</groupId><artifactId>spring-webmvc</artifactId><version>5.2.2.RELEASE</version></dependency>

配置 DispatcherServlet

在 web.xml 文件中配置 DispatcherServlet配置 spring 核心请求分发器<servlet><servlet-name>application</servlet-name><servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class><init-param><param-name>contextConfigLocation</param-name><param-value>classpath:spring.xml</param-value></init-param><load-on-startup>0</load-on-startup></servlet><!-- 请求映射 --><servlet-mapping><servlet-name>application</servlet-name><url-pattern>/</url-pattern></servlet-mapping>

开启 SpringWEB 注解

开启 springweb 注解<mvc:annotation-driven></mvc:annotation-driven>

接收请求

@RequestMapping@RequestMapping 是一个用来为处理器地址映射的注解,可用于类或方法上.作用在类上,在整个项目中不能重复,作用在方法上,整个类中不能重复.常用属性 path,value,method.path 和 value 用来定义地址method 用来定义请求方式@RequestMapping(value = "/hello",method = RequestMethod.GET)@RequestMapping(path= "/hello",method = RequestMethod.POST)

获取请求数据

Spring WEB 支持对多种类型的请求参数进行封装 自定义的处理器 @RestController 为web层类添加的注解标签 @RequestMapping 为类和方法配置映射访问地址,类地址在项目中不能重复 */ @RestController @RequestMapping(path = "/api/loginCtl") public class LoginController { @Autowired private LoginService loginService; /* @RequestMapping(path = "/login")为方法定义地址时,可以指定请求方式 @RequestMapping(path = "/login",method = RequestMethod.POST)意味着只能通过post方法获取请求 也可以通过@PostMapping(path = "/login") @GetMapping(path = "/login") 这两种方式,去直接对访问方式进行限制 */ /* 接收方式1:使用HttpServletRequest对象接收请求中的数据 @PostMapping(path = "/login") public String login(HttpServletRequest request){ System.out.println(request.getParameter("name")); System.out.println(request.getHeader("token")); System.out.println(request.getRemoteAddr()); return "success"; } */ /*方式2:通过定义参数名的方式接收请求中的数据 @PostMapping(path = "/login") public String login(String account,String password,@RequestHeader("token") String token) { System.out.println(account); System.out.println(password); System.out.println(token); return "success"; } */ //方式3:当请求中的参数名与形参不一样时,我们利用注解的方式将请求中的参数与形参进行绑定 /* @PostMapping(path = "/login") public String login(@RequestParam("user-accout") String account, @RequestParam("user-password") String password, @RequestHeader("user-token") String token) { System.out.println(account); System.out.println(password); System.out.println(token); return "success"; } */ /*方式4:后端接收前端提交的json格式的数据: 1.项目中需要添加json转换的组件 2.在对象前添加@RequestBody的注解 */ @PostMapping(path = "/login") public Result login(@RequestBody Admin admin){ Result result = new Result(200,"登陆成功",admin); System.out.println("yes"); return result; } @GetMapping(path = "/test") public String test(){ System.out.println("test"); return "success"; }

拦截器

Spring WEB 中的拦截器(Interceptor)类似于 Servlet 中的过滤器(Filter),它主要用于拦截用户请求并作相应的处理。Spring 中的拦截器与过滤器有着本质的区别,过滤器是 servlet 规范中定义并实现的,在进入到 servlet 之前截获请求.而拦截器是 spring 中定义的一种拦截机制,是对进入到处理器的请求进行拦截.SpringWEB 定义了拦截器接口 HandlerInterceptorboolean preHandle预处理方法,实现处理器方法的预处理,就是在处理器方法执行之前这个方法会被执行,相当于拦截了处理器方法,框架会传递请求和响应对象给该方法,第三个参数为被拦截的处理器。如果 preHandle 方法返回 true 表示继续流程(如调用下一个拦截器或处理器方法),返回 false 表示流程中断,不会继续调用其他的拦截器或处理器方法,此时我们需要通过 response 来产生响应;

拦截器实现

编写一个类,继承 HandlerInterceptorAdapterpublic class DemoInterceptor implements HandlerInterceptor{/*当请求到达控制器之前被执行true--继续向下执行,到达下一个拦截器,或控制器false--不会继续向下执行*/public boolean preHandle(HttpServletRequest request, HttpServletResponseresponse, Object handler)throws Exception {System.out.println("之前执行");return false;}

注册拦截器

<!-- 配置拦截器 --> <mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/><!-- 配置所有请求进入到此拦截器 --> <mvc:exclude-mapping path="/api/loginCtl/login"/><!-- 配置不进入拦截器的地址 --> <bean></bean><!-- 配置拦截器的实现类 --> </mvc:interceptor> </mvc:interceptors>

拦截器具体实现

发送post请求

由于定义过 <mvc:exclude-mapping path="/api/loginCtl/login"/><!-- 配置不进入拦截器的地址 -->,则该请求不会进入拦截器

因此后端会接收到:

同理在发送Get请求给“test”地址时,则会出现

Read more

WhisperLiveKit终极指南:5分钟打造本地实时语音转录神器 [特殊字符]

WhisperLiveKit终极指南:5分钟打造本地实时语音转录神器 🚀 【免费下载链接】WhisperLiveKitReal-time, Fully Local Speech-to-Text and Speaker Diarization. FastAPI Server & Web Interface 项目地址: https://gitcode.com/GitHub_Trending/wh/WhisperLiveKit 想要实现本地实时语音转录和说话人识别,但又担心隐私泄露和云端延迟?WhisperLiveKit正是你需要的解决方案!这个开源工具让你在5分钟内搭建一个完全本地化的实时语音转文字系统,支持多语言转录、说话人分离和实时翻译,无需依赖任何云服务。无论是会议记录、实时字幕还是语音分析,WhisperLiveKit都能提供超低延迟的本地处理能力。 📊 为什么选择WhisperLiveKit? 传统的语音识别工具要么需要云端处理,要么延迟过高无法实时使用。WhisperLiveKit基于最新的实时语音研究技术,包括Simul-Whisper、Streaming So

OpenAI Codex vs GitHub Copilot:哪个更适合你的开发需求?2025年深度对比

OpenAI Codex 与 GitHub Copilot:2025年开发者如何做出关键选择? 在2025年的技术栈里,一个高效的AI编程伙伴不再是锦上添花,而是决定项目节奏与质量的核心生产力。面对市场上功能各异的选择,许多开发者,尤其是那些管理着复杂项目或带领团队的技术决策者,常常陷入一个两难的境地:是选择功能全面、能独立处理任务的“AI工程师”,还是选择无缝集成、提供实时灵感的“智能副驾驶”?这不仅仅是工具的选择,更是关于工作流重塑、团队协作模式乃至项目架构未来的战略决策。对于个人开发者、初创团队乃至大型企业的技术负责人而言,理解这两款主流工具——OpenAI Codex与GitHub Copilot——在本质定位、适用场景与成本效益上的深层差异,是避免资源错配、最大化技术投资回报的第一步。本文将深入它们的核心,帮助你根据真实的开发需求,找到那个最契合的“数字搭档”。 1. 核心理念与定位:从“辅助”到“执行”的范式差异 理解Codex和Copilot,首先要跳出“它们都是写代码的AI”这个笼统印象。它们的底层设计哲学决定了完全不同的应用边界。 OpenAI Codex

AIGC浪潮下,图文内容社区数据指标体系如何构建?

AIGC浪潮下,图文内容社区数据指标体系如何构建?

文章目录 * 01 案例:以图文内容社区为例实践数据指标体构建 * 02 4个步骤实现数据指标体系构建 * 1. 明确业务目标,梳理北极星指标 * 2. 梳理业务流程,明确过程指标 * 3. 指标下钻分级,构建多层级数据指标体系 * 4. 添加分析维度,构建完整的数据指标体系 * 03 构建数据指标体系的过程总结 * 作者简介 * 目 录 数据指标体系构建是数据分析师的日常工作之一,常见的指标体系方法论包括根据业务发展进程选取由合成略旦易于拆解的指标作为北极星指标。但在实际业务场景中如何运用方法论构建数据指标体系,以监控业务发展呢? 互联网产品按照用户需求进行分类,可以分为工具类、内容类、社交类、交易类以及游戏类。当然,每一个互联网产品并不一定属于单一的某一类别,其类别可能是交叉的。 那各种不同类型的互联网产品都有什么特点?它们对应的北极星指标又分别是什么呢?各类型互联网产品的特点以及北极星指标总结如表1所示。 表 1 各类型互联网产品的特点以及北极星指标 表1 各类型互联网产品的特点以及北极星指标 表1各类型互联网产品的特点以及

LangFlow与主流大模型对接教程(支持Llama、ChatGLM、Qwen)

LangFlow与主流大模型对接实践指南 在大语言模型(LLM)技术席卷各行各业的今天,越来越多团队希望快速构建智能问答、内容生成或自动化代理系统。然而,即便拥有强大的模型如Llama、ChatGLM或Qwen,实际落地时仍常被复杂的代码结构、繁琐的调试流程和跨团队协作障碍所困扰。 有没有一种方式,能让非程序员也能参与AI应用设计?能否在几分钟内完成一个RAG系统的原型验证? 答案是肯定的——LangFlow 正是为此而生。 LangFlow 是一个为 LangChain 量身打造的可视化开发工具,它将原本需要数百行Python代码才能实现的语言链路,转化为直观的“拖拽+连线”操作。无论是研究人员想快速测试新思路,还是产品经理要演示智能客服概念,LangFlow都能让这一切变得轻而易举。 它的核心魅力在于:把“编码驱动”的AI开发,变成“流程驱动”的交互式实验。你不再需要逐行写LLMChain、PromptTemplate,而是像搭积木一样组合组件,实时看到每一步输出的变化。 更重要的是,LangFlow 并不局限于某一家模型。它天然支持从 Meta 的 Llama 系列,