Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Types residing in packages registered via @Modulithic(additionalPackages = "…") not observed #587

Closed
9n opened this issue May 11, 2024 · 2 comments
Closed

Types residing in packages registered via @Modulithic(additionalPackages = "…") not observed #587

9n opened this issue May 11, 2024 · 2 comments
Assignees
@odrotbohm
Labels
in: core Core module meta model
Milestone
1.2

Comments

@9n
Copy link

9n commented May 11, 2024

Provided the following package structure:

my-app/
├─ pom.xml
├─ src/
│  ├─ com/example/
│  │  ├─ app/
│  │  │  ├─ Application.java  //annotated with @SpringBootApplication & @Modulithic(additionalPackages = { "com.example.library" })
│  │  │  ├─ moduleA/
│  │  │  ├─ moduleB/
│  │  ├─ library/
│  │  │  ├─ moduleC/
│  │  │  ├─ moduleD/

moduleC and moduleD can't get observed when using spring-modulith-starter-insight.

Inspecting the source code, SpringBootApplicationRuntime.isApplicationClass considers additional AutoConfigurationPackages instead of @Modulithic.additionalPackages.

I can get moduleC and moduleD observed by annotating Application class with @AutoConfigurationPackage(basePackages = "com.example.library"), but I think this behavior is not intuitive. Is this purposed?
@odrotbohm
Copy link
Member

Thanks for reporting. That's a great catch. Most certainly a bug.

@odrotbohm odrotbohm added the in: core Core module meta model label May 14, 2024
@odrotbohm odrotbohm self-assigned this May 14, 2024
@odrotbohm odrotbohm added this to the 1.2 milestone May 14, 2024
@odrotbohm odrotbohm changed the title Application Modules in @Modulithic.additionalPackages can't get observed. Types residing in packages registered via @Modulithic(additionalPackages = "…") not observed May 20, 2024
odrotbohm added a commit that referenced this issue May 20, 2024
@odrotbohm
GH-587 - Additional modulith packages are now considered for applicat…
04c1203 
…ion classes.
odrotbohm added a commit that referenced this issue May 20, 2024
@odrotbohm
GH-587 - ModulithMetadata now exposes all base packages.
21bd2ce 
Previously, we had a variety of places calculating the overall packages to inspect for types. This is now all consolidated into the ModulithMetadata abstraction exposing them directly.
@odrotbohm
Copy link
Member

That's fixed and backported via GH-610 and GH-611.

odrotbohm added a commit that referenced this issue May 20, 2024
@odrotbohm
GH-587 - Avoid repeated lookup of ApplicationModules in ApplicationMo…
e29853f 
…dulesRuntime.
odrotbohm added a commit that referenced this issue May 22, 2024
@odrotbohm
GH-587 - Re-establish proper ApplicationModules instance caching.
cffb0a2 
The previous change unfortunately altered the CacheKey type in a way that it does not result in equal instances for the same set of parameters, primarily because SingletonSupplier does not implement equals(…)/hashCode(). We now resort to include the ModulithMetadata source in the equals(…) / hashCode() calculation rather than the ModulithMetadata instance itself. This also avoids annotation processing during CacheKey instance creation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@odrotbohm odrotbohm

Labels
in: core Core module meta model
Projects
None yet
Milestone
1.2
Development

No branches or pull requests
2 participants
@odrotbohm @9n