lsgwr/spring-boot-online-exam: Docker Setup and Exam Workflow Review

Exam Lifecycle Across Student, Teacher, and Administrator Roles

The project addresses the complete exam administration cycle rather than only delivering a question-and-answer page. Students can inspect available exams, answer questions within a time limit, submit their work, review automatically calculated results, and inspect their submitted records. Teachers can maintain the question bank, import questions in batches, assemble papers, monitor aggregate performance, open individual submissions, and export scores as CSV. Administrators receive those capabilities and can also manage users and subjects.

The role model is enforced through different application experiences. Students see “My Exam Hall” and their own results. Teachers receive the additional question bank, paper, and learning-analysis modules. The administrator navigation adds subject and user management. This makes the project useful for organizations that need to demonstrate or prototype several distinct workflows without assembling separate products for each role.

It is intended for Java and Vue developers who want a concrete reference implementation or an internal evaluation system. The repository also describes a Python implementation, but the README does not document its architecture or operation. The main repository is therefore the only implementation that can be assessed from the available technical detail. The public preview and bundled demo data should be treated as evaluation resources, not evidence that the system is configured for real examinations.

Vue, Spring Boot, and MySQL Request Flow

The repository uses a separated frontend and backend architecture. The backend is a Java 21 and Spring Boot 4.1 application with Spring Data JPA, JWT, and springdoc OpenAPI. The frontend is a Vue 3 single-page application built with Vite, Pinia, Element Plus, WangEditor, and ECharts. MySQL 8 stores users, subjects, questions, exams, submissions, and related records. The database initialization script also supplies demonstration data.

During local development, the Vue development server runs on port 5173. Requests under `/api` are proxied to the backend on port 9527. In the Docker deployment, the Dockerfile first builds the Vue application, copies the generated `dist` directory into the Spring Boot static resources, packages the application, and serves it from a Java 21 runtime. This differs from a separately deployed frontend and API arrangement: the production container presents the compiled SPA and API from one application artifact.

Exam grading is documented at the interaction and presentation level. A countdown is displayed while a student works. Single-choice and judgment questions accept one choice, while multiple-choice questions accept several. Submission is confirmed before the recorded answer view opens. Correct answers are shown in green, incorrect selections in red, and points are displayed per question. The documentation does not expose the internal grading service, submission transaction behavior, or concurrency control, so those implementation details should be inspected in the backend source before high-stakes use.

Docker Compose Startup for the First Examination

The shortest documented path requires Docker and Docker Compose. The Compose file creates a MySQL 8.4 service, configures UTF-8 settings, mounts `doc/sql/exam.sql` as an initialization script, and waits for MySQL to become healthy before starting the application. The application receives the `mysql` hostname and a password through environment variables and exposes port 9527.

Run this command in the repository root. It builds the frontend and backend image, initializes a persistent `exam-db` volume on its first creation, and starts the service stack:

docker compose up --build

Once the stack is ready, open `http://localhost:9527`. Log in as `student` with password `admin123`, open an available exam, and select “Start answering.” The exam page should show its countdown and the documented question types. Submitting the paper should lead to the answer detail view with correctness and per-question scores.

The repository provides three demo identities. Their usernames are `admin`, `teacher`, and `student`, and each uses password `admin123`. The same password across all roles makes the setup convenient for evaluation, but it is a poor production credential pattern. The Compose file also contains the MySQL root password directly. Since the file is part of the repository, deployment operators would need a separate secrets strategy if this were used beyond a local or demonstration environment. The README does not document rollback, migration execution after the first volume creation, or TLS termination.

Local Java and Vue Development Against MySQL

For development outside the container, the README requires JDK 21, either Node.js 20.19+ or 22.12+, Maven, and MySQL 8. The database and demo schema must be created before starting the backend. These commands use the documented schema file and the repository path:

mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS exam CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p exam < doc/sql/exam.sql

Start the Spring Boot API from the `backend` directory. Replace the placeholder with the local MySQL root password; the README states that the backend connects to `exam` on port 3306 by default:

cd backend
DB_PASSWORD='<MySQL root 密码>' mvn spring-boot:run

In another terminal, install the locked frontend dependencies and start the Vite development server:

cd frontend
npm ci
npm run dev

The frontend is then available at `http://localhost:5173`, with `/api` proxied to port 9527. The backend API documentation is listed at `http://localhost:9527/swagger-ui.html`. This split is useful during frontend work because the SPA and API can be developed separately. It also creates more configuration and process management than the Compose route. The README does not list required environment variables beyond the local database password example, nor does it describe how to reset or migrate a database that already has data.

Question Import, Grading Records, and Administrative Limits

The question bank supports rich-text stems and options, difficulty, subject, score, explanations, and question type. Images are described as Base64 content stored in the database. Teachers can download a CSV template, edit it, and import it, or use an `.xlsx` file with the same column order. The documented fields are `type`, `level`, `category`, `score`, `stem`, `optionA`, `optionB`, `optionC`, `optionD`, and `answer`. Accepted type labels include `single`, `multi`, and `judge`, as well as their documented Chinese equivalents.

This import path reduces repetitive entry, but it also makes the template and subject names part of the integration contract. The category must match an existing subject, and answer syntax differs by question type. A malformed value is therefore a likely import failure rather than a general-purpose spreadsheet conversion feature. The README does not state whether the interface reports row-level validation errors, whether imports are transactional, or whether an import can be rolled back.

Exam administration has two notable retention rules. A question referenced by an undeleted exam cannot be deleted directly, and deleting an exam only hides it while leaving its questions in the bank. A subject with questions cannot be deleted. These constraints preserve referential integrity in the documented workflow, but they can also make cleanup less direct. The learning module filters scores by exam and exports CSV. The documentation does not describe grading disputes, answer corrections, proctoring, randomization, negative marking, or accommodations such as extra time.

Maintenance Signals, MIT Licensing, and Alternative Architecture

The repository is not archived, and its recorded last push was on 2026-10-10. The absence of releases means the README and repository history are the available sources for version information; the documentation does not define a release cadence or compatibility policy for upgrades.

The project is licensed under MIT. That license is relevant to organizations reviewing source reuse, modification, and distribution obligations. This article does not provide legal advice, and adopters still need to review the actual `LICENSE` file and account for dependencies, database content, fonts, editor packages, and any separately distributed assets.

A real alternative is a conventional server-rendered Python or Java web application in which the browser submits exam forms to a backend-rendered page. The clear architectural difference available here is that this repository compiles a Vue SPA into the Spring Boot artifact and keeps stateful UI behavior in Pinia, rather than relying primarily on server-rendered HTML. Teams needing a lightweight reference may prefer that simpler approach; teams wanting the documented dashboards, charts, role-specific SPA navigation, and JPA-backed API will find this repository more directly aligned with those features. Neither the README nor release documentation specifies production load limits, so adoption should not be based on an assumed scalability range.

Editorial conclusion

Adopt this project for demonstrations, internal pilots, or a starting point when Java, Vue, and MySQL fit the team. Do not treat the public demo credentials, embedded database password, or undocumented production controls as deployment guidance. Verify authentication hardening, secret management, backup procedures, and exam concurrency requirements before placing real student data in it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lsgwr/spring-boot-online-exam on GitHub
4. Project website
5. README