E-commerce-project-springBoot: a JSP and Hibernate walkthrough of a layered MVC shop

A textbook e-commerce app, deliberately explicit

This repository is a server-rendered e-commerce web application built with Spring Boot, JSP, Spring Security and Hibernate, described as production-oriented and as an easy-to-understand setup for beginners that provides a base foundation in Spring Boot, MVC and Hibernate.

The interesting design decision is the one the README calls out in its highlights list: a custom Hibernate SessionFactory configuration, explicitly described as a non-Spring-Data JPA runtime. Most Spring Boot Hibernate tutorials use Spring Data JPA, where a repository interface and a derived query method do the work. Here the Hibernate ORM is used through LocalSessionFactoryBean, and the data access is hand-written in a DAO layer.

That is a pedagogical choice with real consequences, and it is the reason to look at this project at all rather than at another CRUD sample. A Spring Data repository will appear to work until you need a query it cannot express, at which point you have to learn JPQL and the entity manager anyway. Writing the DAOs by hand from the start means the mechanism is never hidden.

The stack itself is Java 11, Spring Boot 2.6.4, Spring MVC, Spring Security 5.x, Hibernate ORM, JSP with JSTL and Tomcat Jasper for the view layer, the MySQL 8 connector, and Maven for the build. No licence file sits in the repository, and the last push was on 2026-05-08 with no published GitHub releases.

The package layout and what lives in each layer

The project structure is the clearest statement of the architecture, since the directories are the layers.

src/main/java/com/jtspringproject/JtSpringProject/
  configuration/     # Security config
  controller/        # MVC controllers
  dao/               # Data access layer
  models/            # Entities
  services/          # Business layer
  repository/        # Spring Data repository (partial)
  HibernateConfiguration.java
  JtSpringProjectApplication.java
src/main/resources/
  application.properties
src/main/webapp/views/
  *.jsp
basedata.sql
pom.xml

So there is a configuration package for the Spring Security setup, controllers for the MVC layer, a dao package for data access, models for the entities, and services for the business layer. The repository directory is described as a Spring Data repository, partial, which suggests the project was migrated towards or away from Spring Data rather than never having used it, and the two files at the root of the package are the Hibernate configuration and the application entry point.

The views are JSP files under src/main/webapp/views, which is the classic WAR-style layout rather than a src/main/resources/templates layout. That choice means the project runs JSP through the embedded Jasper compiler, and it also means the familiar Spring Boot static resource and template resolution rules apply in a slightly different way, which is the source of the IntelliJ note in the documentation: if JSP views are not resolved, set the run configuration working directory to $MODULE_WORKING_DIR$, and the troubleshooting section repeats the point about verifying the working directory and the spring.mvc.view.prefix=/views/ setting.

The domain is the standard one. The admin modules cover products, categories and customer listing, and the user modules cover registration, login, profile management and product browsing.

Configuration, seeding, and running it locally

The prerequisites are Java 11 or newer, Maven 3.8 or newer, and MySQL or MariaDB.

The clone and the database configuration are two steps:

git clone https://github.com/jaygajera17/E-commerce-project-springBoot.git
cd E-commerce-project-springBoot

The four db.* keys are read from the file by the project, and the driver is com.mysql.cj.jdbc.Driver with a URL pointing at a MySQL instance, where createDatabaseIfNotExist=true creates the schema on first connect. The Hibernate settings set the dialect to MySQL5Dialect, turn SQL logging on with show_sql, set hbm2ddl.auto to update, and point entitymanager.packagesToScan at the com package so entities are discovered.

Two of those lines deserve comment. The createDatabaseIfNotExist=true in the JDBC URL means the schema is created on first connect, which is convenient and means the MySQL user needs permission to create databases. And hibernate.hbm2ddl.auto=update lets Hibernate alter the schema to match the entities at startup, which is a development convenience that silently mutates your database when an entity changes.

The dialect is MySQL5Dialect against a MySQL 8 connector, which is a mismatch worth noting. It works, but it is a signal that the configuration was written for an older target.

The optional seeding step runs basedata.sql against your database for initial categories, users and products, and the documentation includes a note that the sample credentials in basedata.sql are development-only defaults. That note matters: a seed script with known usernames and passwords in a repository people copy is how a demo ends up with a live admin account, so treat it as something to change on sight.

The run commands are standard Maven:

mvn clean package
mvn spring-boot:run

And the app is at http://localhost:8080/.

Routes, roles, and where the security model actually lives

The endpoint list is short and split by role, which is the shape you want to see in a sample with a real security model rather than a mock one.

The public and user routes are /, /login, /register, /newuserregister, /user/products and /profileDisplay. The admin routes are /admin/, /admin/Dashboard, /admin/products, /admin/categories and /admin/customers.

The security model has three rules. Admin routes under /admin/** require the role ADMIN, user routes require the role USER, and the login pages are separate: /admin/login for administrators and /login for users. CSRF protection is enabled for form submissions, which is the correct default for a server-rendered application with session cookies, and the existence of the two login pages suggests a separate filter chain for the admin area rather than a shared one with a role check inside the controller.

The CI/CD story is a Jenkins pipeline file, included with stages for checkout, build, test and a deploy stage that is left as a stub, and the documentation says to adjust the branch, the deployment steps and the credentials for your environment. A stubbed-out deploy stage is a reasonable thing to find in a sample, and also a trap for someone who assumes the pipeline is wired up.

The build and test command is mvn clean verify, with an important note attached: mvn test requires a reachable database because context startup initializes the Hibernate and datasource beans. That is a direct consequence of the hand-wired SessionFactory, and it is the practical downside of that design. A test suite that needs a live MySQL to start cannot run in a fast, hermetic unit test phase, so every build needs a database somewhere.

The troubleshooting section is honest about the failure modes that follow from the same design: an unresolved 'db.driver' property error means the db.* keys are missing from application.properties, and tests failing on startup means MySQL is not running or the credentials are wrong.

What the roadmap says is unfinished

The repository carries a roadmap.md, and the README points to it for the full picture, with the current priorities list starting with a solid foundation of CI and Docker Compose. That single phrase is the most useful thing in the documentation for an adopter, because it tells you the project is not finished and where the gaps are.

The second-order observation is about the stack's age. Spring Boot 2.6.4, Java 11, Spring Security 5.x, a MySQL 5 dialect, JSP rather than a modern template engine, and no Docker Compose in the repository today despite it being a stated priority. Anyone starting a new project on this in 2026 would be building on a Spring Boot line that is several major versions behind, on a Java version that is out of mainstream support, and with a view layer that no longer matches the default in current Spring Boot starters.

That does not make the project a poor learning resource. If anything it makes it a better one for understanding the older idioms, because the explicit SessionFactory wiring, the hand-written DAOs and the DAO and service layering are all things that a Spring Data project hides from you. Reading this alongside a current project is arguably better than reading only the current one.

The other thing to know is that the licence is not stated. No LICENSE file appears among the top level entries, which are .gitignore, .idea, README.md, basedata.sql, the jenkins file, mvnw, mvnw.cmd, pom.xml, roadmap.md and src. For a project you intend to copy code out of, that gap is worth resolving with the author rather than assuming.

Editorial conclusion

This project suits a beginner who wants to read a complete Spring Boot web application end to end, with the security rules, the DAOs, the services and the views all in one repository, and to see how a hand-wired SessionFactory differs from the Spring Data approach many tutorials use. It is a poor fit as a starting point for a new commercial system, because the stack is dated, with Spring Boot 2.6.4, Java 11 and MySQL 5 dialect, and because the seeding script ships default credentials. Before you build on it, change the sample credentials in basedata.sql, set hbm2ddl.auto deliberately, and check the roadmap.md to see which parts of the project the author still considers unfinished.

Frequently asked questions

Official sources

1. Issues
2. jaygajera17/E-commerce-project-springBoot on GitHub
3. Project website
4. README