JavaWeb作业管理系统源码拆解：从Druid连接池到Tomcat部署排错全攻略

简介：面向JavaWeb初学者的作业管理网站完整项目资料包，适配课程设计、毕业设计及Servlet、JSP阶段的实战训练。项目覆盖教师发布作业、学生提交作业、管理员统一管理等功能，围绕Servlet、JSP、JDBC、MVC及常用数据库操作展开，源码结构清晰，适合对照学习传统JavaWeb开发流程。压缩包共53个文件，以9个JSP页面、9个Java类、10个map文件为主，附有jar依赖、CSS/JS前端样式、数据库配置文件等，整体仅7.73MB，便于快速部署与二次修改。已有97人学习使用，说明资料具备一定参考价值。资料内包含完整的MVC分层代码、作业发布/提交/汇总模块、bootstrap前端页面，以及基于druid连接池的数据库配置样例，可帮助读者理解登录鉴权、数据表设计、JDBC封装和安全校验等关键细节。目录层级包含web目录、src源码、META-INF配置等，结构规整，适合按模块拆解学习。

1. 拿到gdes-master压缩包后，先别急着双击运行

把“基于JavaWeb的作业管理网站.zip”解压后看到的gdes-master目录，是一个比想象中完整的Servlet+JSP+JDBC项目。很多人第一次跑这类JavaWeb项目完整案例，习惯先点Idea的Run按钮，结果迎接他的是一堆ClassNotFoundException和数据库连接超时。真正的问题往往不在代码逻辑，而在druid.properties里的参数值、WEB-INF下的依赖包是否齐全，以及Tomcat的访问路径是否带了上下文名。这个项目麻雀虽小，五脏俱全：登录、作业发布、提交作业、收集汇总、信息展示都有，适合正在准备毕业设计或想弄懂JavaWeb底层交互的开发者。你不需要先学Spring，只要懂Servlet生命周期、JDBC基本API和JSP内置对象，就能顺着这套代码把整个请求-响应链路啃下来。我接下来的拆解会从数据层写到控制层，再到前端集成和部署排错，每一步都能对着源码找到对应文件。

2. Druid连接池配置与JDBC数据访问层搭建

2.1 从druid.properties看连接池参数

打开src目录下的druid.properties，你会看到一行行键值对，它们决定了网站怎么连接MySQL。我摘录最典型的配置：

driverClassName=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/gdes?useUnicode=true&characterEncoding=utf-8&useSSL=false username=root password=123456 initialSize=5 maxActive=10 maxWait=3000

这段配置是数据访问层的地基。driverClassName指定MySQL驱动类名，如果你的MySQL是8.0以上，需要改成com.mysql.cj.jdbc.Driver，并在URL里追加serverTimezone=Asia/Shanghai，否则会报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。url中的gdes是数据库库名，useUnicode=true配合characterEncoding=utf-8保证中文正常读写，useSSL=false避免本机调试时出现SSL握手警告。initialSize是连接池初始的连接数，应用一启动就会创建5个物理连接备用；maxActive是池中最大连接数，超过这个数的新请求会进入等待队列；maxWait表示获取连接的最大等待时间，单位毫秒，超过3秒就抛异常。这些参数对作业管理系统来说已经是宽松配置，因为学生提交作业的并发量通常不会超过100。如果把maxActive设置成500，反而会占用MySQL的连接数上限，导致数据库自身的连接不够用。

这里有一个容易踩的坑：Druid的DruidDataSourceFactory.createDataSource(props)要求properties里的key必须是Druid能识别的标准项，如果你误写了driverClassName的别名，比如driverClass，就会抛出property name not found异常。另外，如果项目的lib目录里没有druid的jar包，即使properties写对了，DruidDataSourceFactory类也加载不到。我拿到源码后第一件事就是检查WEB-INF/lib下是否有druid-1.1.x.jar和mysql-connector-java-x.jar，没有就补上，否则后面所有DAO方法都会在静态代码块里直接报ClassNotFoundException。

2.2 封装Druid连接工具类

连接池不会自己工作，你需要一个工具类来从池子里获取Connection。gdes-master里通常有类似DbUtils的类，核心实现如下：

public class DbUtils { private static DruidDataSource dataSource; static { Properties props = new Properties(); try { InputStream is = DbUtils.class.getClassLoader().getResourceAsStream("druid.properties"); props.load(is); dataSource = (DruidDataSource) DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { throw new ExceptionInInitializerError(e); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(ResultSet rs, PreparedStatement ps, Connection conn) { if (rs != null) { try { rs.close(); } catch (SQLException e) { e.printStackTrace(); } } if (ps != null) { try { ps.close(); } catch (SQLException e) { e.printStackTrace(); } } if (conn != null) { try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } } } }

静态代码块在类第一次被加载时执行，后面的线程池中的每一个DAO调用都会复用同一个DruidDataSource实例，避免反复解析配置。getResourceAsStream从classpath根目录读取文件，这意味着druid.properties必须和编译后的class文件在同一个根目录下。在Eclipse或Idea中运行时，src目录的根就是classpath；但如果部署成war包，它会被复制到WEB-INF/classes下。close方法里分别判断rs、ps、conn是否为null，防止对已关闭的结果集重复调用close抛出空指针。需要注意的是，这个close方法关闭的Connection实际上是被Druid代理的，close操作会把物理连接归还连接池，而不是真正断开数据库连接。

使用这个工具类时，我建议把获取连接的代码放在try-with-resources里，比如：

try (Connection conn = DbUtils.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { // 执行操作 }

这样即使中间发生异常，conn也会自动关闭。但DbUtils.close里手动关闭的代码也不冲突，只是两种写法任选其一，不要重复关闭，否则个别版本Druid会输出重复close的警告日志。

2.3 DAO层的增删改查套路

Dao类负责把关系型数据转换成Java对象，这是JDBC项目中代码量最大的部分。以用户表查询为例，源码中的UserDao通常写成这样：

public User findByUsername(String username) throws SQLException { String sql = "SELECT id, username, password, role FROM user WHERE username=?"; try (Connection conn = DbUtils.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { User user = new User(); user.setId(rs.getInt("id")); user.setUsername(rs.getString("username")); user.setPassword(rs.getString("password")); user.setRole(rs.getString("role")); return user; } } } return null; }

这段代码体现了PreparedStatement的两大价值：一是预编译SQL让数据库提前解析语法，多次执行时性能更好；二是setString方法会把传入值包在单引号里并转义危险字符，从底层杜绝SQL注入。这里的?占位符索引从1开始，如果把username放在第二个条件里，就必须用setString(2, username)。getInt("id")是按下标列名获取，如果你改动了SELECT的字段列表，比如把id改成uid，那么这里要同步修改，否则会报Column 'id' not found。一个常见的坏习惯是写SELECT *，然后把rs.getString(1)这种按数字取列的方式写进业务代码，一旦表结构调整，这种代码就会悄悄返回错误数据。我推荐永远写显式列名，并按列名从ResultSet取值，即使多用几个字符，但能让代码在数据库变更时更容易排查。

下面这张表是我维护DAO代码时常用的参数类型对照，项目中同样适用：

如果你要从ResultSet读取时间列，推荐用getTimestamp("create_time")，然后拿到一个java.sql.Timestamp对象，它继承自java.util.Date，可以直接给实体类的时间字段赋值。反过来写入时，如果你的实体类用的是java.util.Date，不能直接setDate，因为java.sql.PreparedStatement没有setDate(java.util.Date)方法，必须先new java.sql.Timestamp(date.getTime())再传入。这个小问题在作业提交时间、截止时间的存取上会反复出现，提前处理好能省很多调试时间。

3. 作业发布、提交、收集的MVC流程与前端表单处理

3.1 页面与Servlet的映射关系

从web目录可以看到index.jsp、login.jsp、issue.jsp、work.jsp、gather.jsp、submit.jsp、information.jsp，再结合com.web包里的Servlet类，就能拼出一条完整的请求链路。我习惯先用一张表把页面、Servlet和动作的对应关系列出来：

这张表不是从源码抄的，而是我从文件名和URL-pattern反推出来的。拿到一个陌生JavaWeb项目，最忌讳从头到尾顺序读代码。正确做法是先打开web.xml，把 和 全部抄出来，再对照JSP页面里form标签的action属性，就能知道每次提交数据会进入哪个Servlet。如果项目用的是注解配置，那就搜索@WebServlet的urlPatterns。很多时候，页面和Servlet并不是一一对应，可能出现submission.jsp和submit.jsp两个名字，但实际指向同一个SubmitServlet，这种命名不统一是历史项目里最常见的问题，只能靠web.xml来判断。

3.2 用MVC思想拆解作业发布流程

作业发布的Controller是IssueServlet，它接收来自issue.jsp的表单数据，再委托HomeworkDao完成数据库插入操作。一个典型的doPost方法如下：

@WebServlet("/issue") public class IssueServlet extends HttpServlet { protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String action = request.getParameter("action"); if ("add".equals(action)) { addHomework(request, response); } else if ("update".equals(action)) { updateHomework(request, response); } } private void addHomework(HttpServletRequest request, HttpServletResponse response) throws IOException { String title = request.getParameter("title"); String content = request.getParameter("content"); String deadline = request.getParameter("deadline"); Homework homework = new Homework(); homework.setTitle(title); homework.setContent(content); homework.setDeadline(java.sql.Date.valueOf(deadline)); HomeworkDao dao = new HomeworkDao(); boolean ok = dao.insert(homework); response.sendRedirect(request.getContextPath() + "/work?status=" + (ok ? "success" : "fail")); } }

这里用service方法统一处理GET和POST，并根据action参数分发到不同的私有方法，是一种常见的轻量级MVC写法，避免了同一Servlet里堆满doGet和doPost。注意在调用getParameter之前必须设置了请求编码，否则之后read的参数全部是乱码。setCharacterEncoding放在service方法第一行是合理的，因为整个方法内只需要设置一次。deadline从请求中拿到的字符串格式可能是"2025-07-01"，而数据库字段类型是date，因此用java.sql.Date.valueOf(String)来转换，它要求严格的yyyy-MM-dd格式。如果前端用的是datetime-local控件，format会变成"2025-07-01T10:20"，这时直接valueOf会抛IllegalArgumentException，需要先把'T'替换成空格再按时间解析。我在这个项目的实际改造中，更倾向于用SimpleDateFormat指定格式，然后new java.sql.Date(sdf.parse(deadlineStr).getTime())，这样可以兼容多种输入格式。

重定向语句response.sendRedirect(request.getContextPath() + "/work")是处理表单提交的标准姿势。它告诉浏览器重新发起一个GET请求到/work路径，这样用户刷新列表页时不会再次触发doPost，避免重复插入同一条作业。如果这里换成request.getRequestDispatcher("/work").forward(request, response)，地址栏不会变化，用户一旦按F5，浏览器会重新提交整个表单，数据库里就会出现两条一样的作业。这个区别在作业提交场景里尤其要重视，我已经见过不少学生因为用了forward导致一节课提交了几十条重复记录。

3.3 学生提交作业时的文件上传与文本处理

submit.jsp实现的是学生把作业答案保存到系统。如果只是提交文本，处理方式与发布作业类似，用getParameter("answer")即可。但如果表单里有附件，前端必须设置enctype="multipart/form-data"，此时Servlet不能再用getParameter获取普通字段，必须从Part中解析。假设表单里有学号studentNo和附件attachment两个字段，Servlet端可以这样写：

@WebServlet("/submit") public class SubmitServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); String studentNo = request.getParameter("studentNo"); // 注意：multipart下这里返回null Part part = request.getPart("attachment"); String submittedFileName = part.getSubmittedFileName(); InputStream in = part.getInputStream(); String savePath = getServletContext().getRealPath("/uploads") + java.io.File.separator + submittedFileName; java.io.FileOutputStream fos = new java.io.FileOutputStream(savePath); byte[] buffer = new byte[8192]; int len; while ((len = in.read(buffer)) != -1) { fos.write(buffer, 0, len); } fos.close(); in.close(); response.sendRedirect(request.getContextPath() + "/work"); } }

注意看，在multipart/form-data请求中，getParameter("studentNo")并不会自动解析普通字段，除非你使用request.getParameter的替代方案，比如先遍历Parts解析非文件域，或者用第三方库如commons-fileupload。很多初学者在这里卡住，以为代码没写对，实际上是因为没有处理multipart的格式。如果项目使用Servlet 3.0的@MultipartConfig注解，或者web.xml中配置了multipart-config，Tomcat才会把请求体封装成Part对象组。另外，part.getSubmittedFileName()只在Tomcat 8.5+可用，Tomcat 7下会返回null，需要从Content-Disposition头正则解析。文件保存路径getRealPath("/uploads")返回的是部署目录下的物理路径，如果目录不存在，FileOutputStream会抛FileNotFoundException，所以先要new File(savePath).getParentFile().mkdirs()。保存文件名建议用UUID替换原始名，防止不同学生上传同名文件互相覆盖，同时在数据库里保留原始文件名用于显示下载列表。

4. 登录鉴权与SQL注入防护：从Filter到PreparedStatement

4.1 用Filter拦截未登录请求

没有登录就访问作业列表，这个系统就是裸奔的。gdes-master里一般会有一个AuthFilter，专门负责在请求到达Servlet之前检查Session。以下代码可以直接复用到任何JavaWeb项目中：

@WebFilter("/*") public class AuthFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); // 放行登录页、登录接口和静态资源 if (uri.endsWith("login.jsp") || uri.endsWith("LoginServlet") || uri.contains("/css/") || uri.contains("/js/") || uri.contains("/images/") || uri.endsWith(".css") || uri.endsWith(".js")) { chain.doFilter(request, response); return; } // 校验session中是否存在用户信息 Object user = request.getSession().getAttribute("user"); if (user != null) { chain.doFilter(request, response); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } } }

这段过滤器的逻辑可以归纳为一个两张表的判断：哪些请求是公开的，哪些请求必须登录。

这里最容易被忽略的是静态资源放行。如果不放行.css和.js，那么即便你成功登录，浏览器解析login.jsp时也会因为样式表被Filter重定向到登录页，导致整个页面没有样式，看起来像是白屏。实际排查时，你会在Network面板里看到一堆302响应。对于需要区分角色的页面，比如只有老师能访问issue.jsp，可以在判断user不为null之后，再检查user.getRole()。更规范的做法是定义角色常量，比如"teacher"、"student"，并根据路径前缀配置角色权限映射表。要注意，Session中的user对象必须是登录成功时放入的，且每次请求都要从Session重新读取，不能使用静态变量保存用户信息，否则多个用户之间会发生串号。

4.2 登录SQL的预编译写法与密码加密

在LoginServlet中，最危险的代码是这样写的：

String sql = "SELECT * FROM user WHERE username='" + username + "' AND password='" + password + "'";

如果username输入admin' --，这条SQL就会变成WHERE username='admin' -- ' AND password='，后面的密码判断被注释掉，直接绕过登录。这类漏洞在各大漏洞平台上已经出现无数次，修复方法只有一条：使用PreparedStatement。我给出的标准写法是：

String sql = "SELECT * FROM user WHERE username=? AND password=?"; try (Connection conn = DbUtils.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username.trim()); ps.setString(2, md5(password + salt)); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { // 登录成功 } } }

这里有两个细节。第一，username在传入之前先trim掉首尾空格，避免用户误输入空格导致查不到数据。第二，密码不能明文比对，正确的做法是在注册时生成一个随机盐值，把md5(盐+密码)存进数据库，登录时用同样的盐拼接输入值计算摘要再比对。如果整个项目里密码都是明文存储，我建议你增加一个统一的加密工具类。除了登录，其他所有涉及用户输入的SQL、排序字段、模糊查询参数，都必须使用?占位符。JPA或MyBatis的#{}本质上也是预编译，但如果你在项目里用了字符串拼接的ORDER BY，仍然无法防注入，因为ORDER BY后面不能绑定参数，这种情况下只能用白名单校验，比如把允许的排序字段放在数组里进行匹配。

4.3 角色权限控制的前后端配合

作业管理系统通常有两种用户角色：教师和学生。教师能发布作业、查看收集情况、管理所有记录；学生只能查看作业列表、提交自己的作业。这种权限差异除了在按钮上做隐藏，服务端必须同样校验。我在AuthFilter里会再增加一个角色-资源映射表，比如：

实现方式是，先根据当前URI判断用户需要哪种角色，再把Session中的user.getRole()与要求比对。前端隐藏按钮只是提升用户体验，真正的安全边界在服务端。另外注意，像issue.jsp这样的动态页面，如果用户猜到路径直接访问，而Servlet接口又没有做角色校验，就必须在Servlet入口也加一次session检查。我在实际审查这个项目时，除了Filter，还会在IssueServlet的service方法第一行加一个简单的HttpSession session = request.getSession(false); if (session == null || !"teacher".equals(session.getAttribute("role")))，这种双保险能有效防止配置漏网。

5. Bootstrap+jQuery页面集成与Tomcat部署常见故障排除

5.1 静态资源路径为什么不加载

在JSP页面里使用相对路径是最容易踩的坑。比如在index.jsp中写<link href="bootstrap-4.3.1-dist/css/bootstrap.min.css">，当页面URL是/gdes/index.jsp时，浏览器请求的资源路径是/gdes/bootstrap-4.3.1-dist/css/bootstrap.min.css，这没问题。但当页面通过/work这个Servlet转发到/work.jsp时，地址栏显示的是/gdes/work，此时相对路径就会解析成/gdes/bootstrap-4.3.1-dist/...，仍然正确吗？不一定，因为Servlet映射是/work，没有后缀，相对路径是基于最后一个/的位置。如果URL是/gdes/work/list，相对路径就会变成/gdes/work/bootstrap...，然后就404。解决这个问题，永远只使用绝对上下文路径：

<link rel="stylesheet" href="${pageContext.request.contextPath}/bootstrap-4.3.1-dist/css/bootstrap.min.css">

${pageContext.request.contextPath}会输出项目上下文名，例如/gdes。这样无论请求被转发多少次，前缀始终是项目根。同样，Ajax请求的URL也要拼接这个前缀，否则在servlet路径下发起url:"/gather"，会访问到http://localhost:8080/gather，而Tomcat默认端口8080根目录没有这个应用，返回404。

5.2 Tomcat启动时连接池初始化失败排查

当你在Catalina日志中看到Cannot create PoolableConnectionFactory时，说明数据层有硬伤。按照下面四步排查，通常能在五分钟内定位问题：

1. 确认MySQL服务是否启动：命令行执行mysql -uroot -p -e "show databases"，能列出库就说明服务正常。
2. 检查druid.properties中的用户名密码是否有特殊字符，如果密码包含#或=，properties解析会截断，需要用反斜杠转义或改用其他方式加载。
3. 核对JDBC URL中的数据库名gdes是否存在，mysql -uroot -p -e "use gdes"测试。
4. 确认WEB-INF/lib目录下已经有mysql驱动jar包。如果你用的是Tomcat 10，还需要把javax.servlet的依赖切换为jakarta.servlet，否则Servlet类会报ClassNotFoundException。

我在实际部署这个项目时，最常遇到的其实是数据库版本和驱动不匹配。MySQL 8.0用MySQL 5.x的驱动，会报Communications link failure。检查方式是在Tomcat的lib目录下看jar包名称，5.x驱动是mysql-connector-java-5.1.x.jar，8.x驱动是mysql-connector-java-8.0.x.jar或mysql-connector-j-8.x.jar，后者内部类名才是com.mysql.cj.jdbc.Driver。

5.3 中文参数乱码的三处设防

这个项目的JSP页面如果没设置编码，就会出现中文乱码。你需要检查三处设置。第一处，JSP页面顶部必须写：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

第二处，Servlet读取参数前调用request.setCharacterEncoding("UTF-8")，这个调用要放在第一次getParameter之前。第三处，JDBC URL中加上characterEncoding=utf-8。如果这三处都做了但GET请求仍然乱码，还需要修改Tomcat的server.xml。在<Connector>这个标签上加URIEncoding="UTF-8"，否则Tomcat 8以前的版本默认用ISO-8859-1解析URL。由于源码里的useUnicode=true已经指定了Unicode，所以问题更可能出现在前两处。建议用浏览器开发者工具看Response Headers里的Content-Type，如果显示text/html;charset=UTF-8，说明JSP设置已生效。

5.4 用开发者工具快速定位404和500

页面打不开时，不要直接猜是代码问题。按F12打开Network面板，刷新页面，点击报错的请求看状态码：404表示路径错误，看请求URL和实际Servlet映射；500表示Java代码异常，切换到Console或服务器日志看异常栈。比如你访问/submit返回404，但web.xml里明明配置了SubmitServlet，这时检查一下是不是项目上下文名漏了。Tomcat的默认部署方式是把war包解压到webapps下，上下文名就是war包名。如果war包叫gdes.war，访问地址必须是http://localhost:8080/gdes/，如果只访问http://localhost:8080/就会404。为了减少这类问题，我通常会在所有JSP的form action和重定向路径前都加上${pageContext.request.contextPath}，这样即便换了一个部署名，代码也能继续工作。对于500错误，重点看异常栈中的Caused by部分，那才是根源。最常见的是ClassNotFoundException，说明jar包缺失；其次是SQLException: Table 'gdes.homework' doesn't exist，说明数据库脚本没有执行或者表名不一致。检查gdes-master目录下是否有.sql文件，导入到MySQL后，再对比Entity类和表的字段名是否一一对应。总之，把错误定位到具体文件和行号，比盲目修改代码高效十倍。

本文还有配套的精品资源，点击获取