# forest: a knowledge community backend on Spring Boot and Shiro

> forest is an MIT licensed Java backend for a forum style knowledge community, built with Spring Boot, Shiro, MyBatis, JWT and Redis, with a rich Markdown editor, tags, replies, email verified password reset and a companion front end project called nebula. It suits a developer who wants a runnable community platform skeleton to study or fork, and it is a poor fit if you need a maintained, multi tenant community product.

**rymcu/forest** — forest(森林)——一款现代化的知识社区后台项目，使用 SpringBoot + Shiro + MyBatis + JWT + Redis 实现

- Repository: https://github.com/rymcu/forest
- Website: https://rymcu.com
- Stars: 813 · Forks: 149
- Language: Java
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/rymcu-forest

## A forum backend assembled from the standard Java stack

forest is described as a modern knowledge community project implemented with Spring Boot, Shiro, MyBatis, JWT and Redis, and its own README calls it a next generation knowledge community system built for the future.

Every one of those names carries a decision. Spring Boot supplies the application skeleton and the auto configuration. MyBatis is the persistence layer, which means SQL and mapper interfaces rather than a full ORM. Shiro is the security framework, and it is the older choice compared with Spring Security, which is a reasonable trade for a project that wants a compact authentication stack rather than the whole Spring ecosystem. JWT carries the token, and Redis holds sessions and cache.

The project is MIT licensed with a LICENSE file in the repository root, the primary language is Java, the homepage is rymcu.com, and there are no published GitHub releases. The last push to the repository was on 2026-04-10, so this is a code base you read and run rather than one you upgrade.

The origin story is in the motivation section, and it explains the shape of the project. On a day in 2019, invited by Hugh, the author set out to build an open source platform for embedded knowledge, learning and exchange. The project was inspired by Symphony and builds on Symphony and the B3log thinking, and it explores further in that direction.

The practical consequence is that this is a community platform with a specific idea of what a community is: threaded discussions, tags, a reputation or currency system, and rich content, rather than a flat blog with comments.

## The editor is the feature, and it covers a lot of ground

The largest block in the feature list is the content editor, and the detail is what makes this project interesting to read.

At the base is Markdown with GitHub Flavored Markdown, plus emoji support. Files can be uploaded, covering images and general files, with MP3 files rendered on their own and video files rendered on their own rather than as attachments.

Clipboard handling is treated as a first class feature. Pasted content is processed into Markdown, and a pasted image is automatically re-uploaded, which is the detail that makes the difference between an editor that feels native and one that does not.

There is support for mathematical formulas in LaTeX and for flowcharts, which tells you the target audience writes technical notes rather than short comments.

The toolbar carries emoji, bold, italic, quote, unordered list, ordered list, link, upload, preview and fullscreen, and there are three editing modes. The traditional Markdown split view with editing on one side and preview on the other, an instant rendering mode that preserves the Markdown markers, and a rich text style what you see is what you get mode.

Three editing modes for the same content is an unusual amount of attention to spend, and it is the clearest signal in the repository about what the author cared about. A community platform lives or dies on whether people are willing to write in it, and the editor is where that willingness is won or lost.

## Accounts, tags and the reply model

The rest of the feature list is a small, complete forum model, and reading it tells you what the system does and does not attempt.

Registration takes a username, an email address and a captcha. Login accepts an account, which is either a username or an email, together with a password, and there is a forgotten password flow that works by email with email verification.

Posting supports a post type, currently a normal post, with a title, a body written in the editor, and tags. Tags are the interesting part. You can use an existing tag, chosen with a select and autocomplete, or create a new one, and there is a default pending category tag applied when a post has none. That default is a small piece of workflow design: posts without a tag land in a review state rather than in the open, and the community can then sort them into categories later.

Once published, a post can be updated or deleted, and the browsing view shows the publication time, the view count and the tags. There is also sharing, with a WeChat share and a share link that carries the user identifier, so a link points at the author as well as the post.

Replies have their own editor and support replying to a reply, which makes the structure genuinely threaded rather than a flat comment list. There is also a currency section with currency rules, which is the project version of a reputation system, and given the B3log lineage that is consistent with where the design comes from.

What is absent is as informative. There is no mention of moderation queues, private messages, search, or administration tooling beyond the pending category, so this is a community platform skeleton rather than a complete product.

## Local development needs Redis and MySQL from compose

The Tips section of the README is where the practical setup lives, and it is short.

In the docker dev directory, running docker-compose up initialises the redis and mysql environment, and the README points to the forest user manual, UserManual.md, for more of the tutorial.

```bash
docker-compose up
```

So the development path is: start the two stateful services with compose, then run the application against them. That split is the usual shape for a Spring Boot project with an external database and Redis, and it keeps the application itself runnable from an IDE rather than requiring a full stack in a container.

The second tip in that section is the one that tells you what the project is really for. It recommends using it together with the companion front end project nebula, and frames the two as something to enjoy together while exploring the future of knowledge communities.

That pairing is the key adoption fact. forest is a backend with no interface of its own, and nebula is the interface. A team that wants to see this working needs both repositories, and a team that wants a community product needs both plus a great deal more, because nothing in the feature list covers administration, moderation or reporting.

The repository layout is consistent with that scope. There is a src directory, a pom.xml, a Dockerfile, a docker directory, the mvnw wrapper and mvnw.cmd for Maven, a UserManual.md, and an .onedev-buildspec.yml for the CI system the project uses.

## The container runs a WAR file on Tomcat with Java 8

The Dockerfile in the repository root is short, and it tells you the deployment shape.

```dockerfile
FROM rymcu/java-container:1.0.0

MAINTAINER rymcu.com

COPY target/forest.war /usr/local/tomcat/webapps/

ENV JAVA_HOME=/usr/lib/jvm/jdk1.8.0_202

ENV PATH=$JAVA_HOME/bin:$PATH

CMD ["/usr/local/tomcat/bin/catalina.sh", "run"]

EXPOSE 8080
```

So the application is packaged as a WAR file, copied into the webapps directory of a Tomcat installation, and started with catalina.sh on port 8080. The build assumes a Maven build has already produced target/forest.war, which is what the mvnw wrapper in the repository root is for.

Two things in that file are dated in a way worth noting. The base image is a Java 8 runtime, with JAVA_HOME pointing at a jdk1.8.0_202 directory, and the file uses the older MAINTAINER instruction rather than a LABEL. Neither prevents the container from running, but both tell you that this deployment path has not been revisited in a while.

The Tomcat base is also a deliberate choice rather than a jar-with-a-JRE-and-a-main-class setup. A WAR deployment means the application runs inside a servlet container, which is convenient when you want the same artifact to drop into an existing Tomcat, and less convenient when you want a small image or a cloud native shape.

For a reviewer, the useful consequence is that you can read this Dockerfile, pull the base image, drop a WAR in and see the application, which is a much shorter path than understanding a Maven profile matrix.

## The project asks for security reports alongside bug reports

There are two short sections in the README about reporting problems, and one of them is worth reading carefully.

The bug report section says the community system may have potential defects and invites people to help, and asks that reports be posted with a bug screenshot and the steps to reproduce. It names two categories: functional defects, with publishing an article failing and creating a portfolio failing given as examples, and security vulnerabilities, with XSS, CSRF and theft of user information given as examples.

Naming XSS and CSRF explicitly in a community platform is a statement about where the risk is, because a forum runs user content, and user content in an editor that renders Markdown, supports LaTeX, accepts pasted HTML and embeds images is a rich target. The fact that the project says out loud which classes of bug it wants reported is a sign of a maintainer who would rather know.

The feature suggestion section is equally practical. It invites suggestions, says they will discuss them and implement them where possible, and points at a roadmap board before you propose anything, so that people do not file the same idea twice.

The acknowledgements section thanks the contributors and notes that JetBrains provided the author with an open source licence for their tools, and the project carries a FOSSA badge for licence and dependency scanning, which is a way of showing that the scanning is wired into the build rather than being a one off audit.

The last push to the repository was on 2026-04-10 and there are no published releases, so the code you would run is a snapshot rather than a versioned product, and the open defect list is a real factor in any decision to deploy it.

## Conclusion

forest suits a developer who wants a complete community backend in the classic Java stack to read, run and extend, since the feature list covers the parts that are tedious to rebuild, which are the editor, the account flows, tagging and replies, and the companion front end project means you can see the whole thing rather than only an API. It does not suit a team shipping a community product today, because the last push to the repository was on 2026-04-10 with no published releases, and the project itself invites reports of functional defects and of security issues such as XSS, CSRF and user information theft, which tells you the state of the code. Before you deploy it, read UserManual.md, bring up the Redis and MySQL services from the docker dev directory with docker-compose up, and run it inside the container image that the Dockerfile expects, which ships the application as a WAR file on Tomcat with Java 8 and port 8080.

## FAQ

### What is the forest project?

It is a modern knowledge community backend written in Java with Spring Boot, Shiro, MyBatis, JWT and Redis. It covers a Markdown editor with uploads, LaTeX and flowcharts, registration and login, posting with tags, threaded replies, sharing and a currency system, and it is designed to be used with the companion nebula front end project.

### How do I run forest locally?

In the docker dev directory, run docker-compose up to initialise the redis and mysql environment, then run the application against it. The README points to UserManual.md, the forest user manual, for the rest of the tutorial.

### How is the forest application deployed in its container image?

The Dockerfile copies target/forest.war into the webapps directory of a Tomcat installation in the rymcu/java-container image, sets JAVA_HOME to a Java 8 path, starts catalina.sh and exposes port 8080.

### What should I know about forest's security reporting?

The README asks for bug reports with a screenshot and reproduction steps and names two categories, functional defects and security vulnerabilities such as XSS, CSRF and theft of user information. It also points at a roadmap board before feature suggestions so that ideas are not proposed twice.

### What licence is forest released under?

It is MIT licensed, with the LICENSE file in the repository root and a FOSSA badge for licence and dependency scanning. The project is written in Java and is developed by the rymcu author, with the homepage at rymcu.com.

## Sources

- [Issues](https://github.com/rymcu/forest/issues)
- [License: MIT](https://github.com/rymcu/forest/blob/master/LICENSE)
- [Project website](https://rymcu.com)
- [README](https://github.com/rymcu/forest/blob/master/README.md)
- [rymcu/forest on GitHub](https://github.com/rymcu/forest)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rymcu-forest