# hasor-old: the retired Hasor monorepo, and the six projects that replaced it

> The hasor-old repository is frozen and explicitly unmaintained, and it now serves as a map: each of the original Hasor modules has been split into an independently released project, from Cobble for utilities to Meteor for RPC and Neta for network applications.

**zycgit/hasor-old** — Hasor是一套基于 Java 语言的开发框架，区别于其它框架的是 Hasor 有着自己一套完整的体系，同时还可以和先有技术体系做到完美融合。它包含：IoC/Aop容器框架、Web框架、Jdbc框架、RSF分布式RPC框架、DataQL引擎，等几块。

- Repository: https://github.com/zycgit/hasor-old
- Website: http://www.hasor.net
- Stars: 1,000 · Forks: 267
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/zycgit-hasor-old

## The repository is frozen, and says so in its title

The README heading is Hasor, marked as the old repository with maintenance stopped. The notice is unambiguous: this repository is unmaintained, it keeps only the old Hasor source and history, and there will be no further feature development, no bug fixes and no version releases. For usage, problem reports and code contributions, you are pointed to separate independent projects.

That framing is what makes the repository still useful rather than merely dead. The old code stays where it was, but the README's job has changed from documenting a framework to documenting a migration.

The original Hasor was a Java development framework distinguished from other frameworks by having a complete system of its own while still integrating with existing technology stacks. It contained an IoC and AOP container framework, a web framework, a JDBC framework, an RSF distributed RPC framework and a DataQL engine.

So it was not a single library but a stack, and that is why the split into six projects happened by responsibility. The README states the split explicitly: the capabilities of the original Hasor repository have been divided into 6 projects, each evolving independently around its own domain, and an application can pick what it needs or combine them.

The licence position is also stated per repository. The historical code in this repository continues under Apache License 2.0, and the licences of the new projects are to be found in their own repositories. The project is Apache-2.0 licensed, the primary language is Java, the last push was on 2026-10-05, and there are no published GitHub releases.

## The mapping table, which is the actual content of the repository

The core of the README is a table with four columns, the old module, the new project name, and the Gitee and GitHub addresses for each. Every row of the old tree has an owner now.

The commons module, hasor-commons, became Cobble. The core and web modules, hasor-core and hasor-web, became Hasor, which is the name that was kept for the application container and web framework. The dataql module became DataQL and Dataway. The db module became dbVisitor. The rsf module became Meteor. And the tconsole module became Neta.

The pattern is worth reading. The two modules that together make up the application container and the web layer kept the Hasor name, because that is the part a user thinks of as the framework. The other four were renamed because the old names described what they did inside Hasor rather than what they are on their own. dbVisitor is a name, hasor-db was a location.

The README is also clear about the process for anyone actually moving. Find the module you use in the table, go to the corresponding project, and read its current documentation for versions and integration. The dependency coordinates, package names, configuration and startup method are whatever the new project's documentation says, and you should check them item by item during a migration.

And there is a warning about the content of this repository itself: the descriptions and examples here correspond only to the old code. New feature requests, problem reports and pull requests belong in the corresponding new projects. So the value of reading hasor-old is historical and navigational, not instructional.

## Cobble and Hasor, the foundation and the container

Cobble takes over the general tooling from hasor-commons, and it is the piece that a plain Java application would use without adopting the framework. It contains cobble-lang for utilities and components, cobble-dynamic for dynamic proxies, cobble-loader for resource scanning and class loading, and cobble-settings for configuration access. The stated value is settling general capabilities into an independently reusable base library, offering tools, dynamic proxies, resource loading and configuration support to ordinary Java applications and to other frameworks, so the same code does not get written twice.

Hasor itself takes over hasor-core and hasor-web, and it is the application container and the web development framework. It provides IoC and dependency injection, AOP, module extension, event and lifecycle management, and on the web side, Web MVC, parameter binding and response rendering. The new project also adds hasor-config for declarative configuration, hasor-boot for application startup, executable JAR packaging and embedded web container integration.

That last group is a real addition rather than a straight move, and it is the part that makes the new Hasor worth looking at on its own terms. An application can start from the core container and add configuration, web and startup capabilities as it needs them, which is a different progression from the old all-in-one distribution.

The stated value here is a single development style for object management, module assembly and web development in a Java application.

## DataQL, dbVisitor, Meteor and Neta

The remaining four projects are the parts that were previously framework-internal.

DataQL and Dataway come from hasor-dataql, and they cover data querying, aggregation and API development. There is a DataQL query language with its execution engine, SQL query support, and Dataway for building and managing data interfaces. The claim is that you can do data querying, structure transformation and multi-source aggregation, edit, debug and publish interfaces through a console, or call them from a Java API. The engine can be used on its own, and Dataway can be embedded in an existing application to reuse data sources and business services.

dbVisitor comes from hasor-db and is unified data access. It provides JDBC-based data access, object mapping, dynamic SQL, pagination, session and transaction management, with a JdbcTemplate, a declarative Mapper, a general Mapper and a Lambda query builder, and through JDBC adapters it reaches Redis, MongoDB, Elasticsearch and Milvus. The stated value is one consistent data access style across relational and already-adapted non-relational stores, keeping native SQL and DSL flexibility while cutting the common CRUD code, and it can be used standalone or integrated with Spring, Solon and Hasor.

Meteor comes from hasor-rsf and is the distributed RPC piece. It carries the RSF RPC invocation and service management, call filters, address management, routing and flow control, serialization, plus RSF over TCP, HTTP and Hprose protocol connectors, with the main modules being rsf-framework, rsf-final and the connector modules. The value claim is turning remote service calls into an RPC framework that can be embedded in an application.

Neta comes from hasor-tconsole and is the network application framework with its interactive console. The tConsole itself lives in Neta under neta-lab/tconsole and contains a Telnet server, a client, and an interactive console based on standard input and output, and Neta adds asynchronous network communication, TCP and UDP, codec pipelines and HTTP protocol support. The value is composable communication and codec capability for network services, with the console giving an application a command, debugging and management entry point.

## The old tree, and what it tells you about the split

The repository layout is the old monorepo, unchanged, and it maps one to one onto the new projects.

There is hasor-all, which was the aggregate distribution, and hasor-commons, hasor-core, hasor-dataql, hasor-db, hasor-rsf, hasor-tconsole and hasor-web, the seven modules. There is an example/ directory with its own pom.xml and a src tree, an _exile/ directory that is not referenced by the build, and a top level pom.xml with mvnw and mvnw.cmd, so the Maven wrapper is checked in.

The build is a plain Maven multi-module project, and the presence of .travis.yml alongside a .mvn/ directory dates the repository to a period when Travis was the CI system of choice, which is a useful signal about how old the code here is.

The dependency on the old structure is worth stating plainly. There is no compatibility shim and no version to track, since the repository will not publish releases, so a project that stays on the old modules is depending on code that will not be patched. The migration advice is the only forward path the README offers, and it is deliberately minimal: locate your module, go to the new project, and verify each coordinate, package name, configuration key and startup step against that project's own documentation.

The licence split is the one thing that does carry over cleanly. Apache License 2.0 covers the historical code in this repository, and each of the six new projects carries its own terms, so a fork that mixes old and new code has to read two sets of files.

## Conclusion

hasor-old fits a developer maintaining an older Hasor codebase who needs to know where each module moved, or a reader who wants to see what a full-stack Java framework looked like before it was split up. It is a poor fit for anything new, because the repository is explicitly frozen with no feature development, no bug fixes and no version releases, and using the old modules means using code that will not be patched. Before you start a migration, use the module mapping table in the README to find the successor for each module you actually depend on, and check that project's own documentation for the current coordinates, package names and startup sequence rather than assuming they are unchanged.

## FAQ

### What is the hasor-old repository?

It is the old Hasor repository, explicitly unmaintained, kept only for the old Hasor source and history with no further feature development, bug fixes or version releases. The README's purpose is now to point users at the separate projects that took over each module.

### Which projects replaced the old Hasor modules?

The mapping is hasor-commons to Cobble, hasor-core and hasor-web to Hasor, hasor-dataql to DataQL and Dataway, hasor-db to dbVisitor, hasor-rsf to Meteor, and hasor-tconsole to Neta. Each is published on both Gitee and GitHub under the zycgit organisation.

### What does dbVisitor provide in place of hasor-db?

It provides JDBC-based data access, object mapping, dynamic SQL, pagination, and session and transaction management, with a JdbcTemplate, a declarative Mapper, a general Mapper and a Lambda query builder, and it reaches Redis, MongoDB, Elasticsearch and Milvus through JDBC adapters. It can be used standalone or integrated with Spring, Solon and Hasor.

### What is Dataway and how does it differ from DataQL?

Both come from hasor-dataql. The project covers a DataQL query language with its execution engine and SQL query support, while Dataway is the data interface development and management capability, letting you edit, debug and publish interfaces through a console or call them from a Java API.

## Sources

- [Issues](https://github.com/zycgit/hasor-old/issues)
- [License: Apache-2.0](https://github.com/zycgit/hasor-old/blob/master/LICENSE)
- [Project website](http://www.hasor.net)
- [README](https://github.com/zycgit/hasor-old/blob/master/README.md)
- [zycgit/hasor-old on GitHub](https://github.com/zycgit/hasor-old)

---

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