How to override an entity already replaced with @ReplaceEntity from another addon?

Support
#1

Hi everyone,

I’m working on a modular Jmix project and need some advice on advanced entity replacement.

Project structure:

  • I have a main application: Project C
  • It depends on Addon A, which defines a base entity ACity
  • It also depends on Addon B, which itself depends on Addon A, and replaces ACity with BCity using @ReplaceEntity(ACity.class)

Now in Project C, I need to replace BCity with my own version CCity, while retaining all fields and behavior from both ACity and BCity.

The Problem:

When I try to define CCity as @ReplaceEntity(BCity.class), I encounter issues during build or runtime

It seems like Jmix doesn’t support cascading @ReplaceEntity annotations, i.e., replacing something that’s already a replacement.

My Questions:

  1. Is there a supported way to override an entity that was already overridden in an addon?
  2. Can I somehow build a proper inheritance chain ACity → BCity → CCity that Jmix can work with?
  3. Are there alternative patterns for this scenario — e.g. composition over inheritance, entity extension, or some metadata trick?
  4. Are there any best practices for designing entities in addon layers where this type of re-replacement might be needed later?

I appreciate any guidance, patterns, or real-world experience with this type of setup.

Thanks in advance!

#2

Hi, while I don’t know the answer about the inheritance mechanics involved, I just can’t resist asking you something.
So CCity contains all the fields from ACity and BCity.
It’s part of the main ProjectC, which is the “source”.
AddonA contains ACity, and it has some but not all fields from CCity → fine, so inherit ACity from CCity without the fields not needed.
AddonB contains BCity, which also has some but not all the fields from the CCity - inherit from CCity or ACity.
CCity → ACity → BCity

How about declaring these entities the usual way, without replacing annotations or inheritance? They would point to the same database table, just not contain unneeded fields?

Kind regards,
Mladen

1 Like
#3

Hi Mladen,

Thanks a lot for your input and the attention to my question — I really appreciate it!

To clarify the structure a bit more:

In Addon B, BCity is not just a lightweight wrapper or an optional override — it’s actively used there, along with its custom fields and logic. Project C, being the final application, consumes the result of module B, including BCity, but also adds its own business logic and fields, effectively turning it into CCity.

So, even though it makes perfect sense that CCity could extend ACity (as the base), it’s also necessary for it to include everything BCity added, not just ACity. Ideally, we want the final entity to look like:

CCity = ACity + BCity additions + C-specific fields

Regarding your suggestion about pointing multiple entities to the same table without replacing or inheritance — that’s an interesting idea and can help a little in other cases, but in our case, we need a unified entity with full metadata (fields, relationships, views, fetchplans, etc.) because it’s deeply used across UI and logic layers.

Still, your perspective is helpful and got me thinking about possible ways to flatten or simplify the model.

Thanks again!

Kind regards,
Maxim!