gnodet commented on PR #12551:
URL: https://github.com/apache/maven/pull/12551#issuecomment-5096480543
### Correction: Maven 3.10.x + Sisu 1.1.0 + Mimir WORKS
I was wrong — the code IS different between Maven 3 and Maven 4. Retested
properly with Mimir enabled on both:
| Scenario | Result |
|---|---|
| Maven 3.10.x + Sisu 1.1.0 + Mimir (fresh state) | ✅ **passes** — daemon
resolved, started, build succeeds |
| Maven 4.1.0-SNAPSHOT + Sisu 1.1.0 + Mimir (fresh state) | ❌ `Unknown
NameMapper name: 'file-gaecv', known ones: []` |
Same machine, same Mimir 0.12.0, same clean state (daemon JAR + socket
removed).
### The difference: eager vs lazy Map resolution
**Maven 3**: Guice/Sisu resolves `Map<String, NameMapper>` **eagerly at
injection time** (container startup). At that point TCCL = container realm →
Sisu 1.1.0's FilteredBeans sees all beans → NameMapper map populated with all 9
implementations.
**Maven 4**: `SisuDiBridgeModule.getMapSupplier()` wraps the map resolution
in a **lazy lambda**:
```java
return () -> {
// ...
for (var bean : locator.get().locate(toGuiceKey(valueType))) { // <--
deferred!
// ...
}
};
```
This lambda is first invoked during `DefaultSessionData.computeIfAbsent()`
inside Mimir's `afterSessionStart` callback, where `callListeners()` has set
TCCL = extension realm → Sisu 1.1.0 FilteredBeans sees zero beans → `known
ones: []`.
### Root cause
The Maven 4 DI bridge defers Sisu bean iteration to first access. When that
first access happens inside an extension's lifecycle callback (with TCCL scoped
to the extension's ClassRealm), Sisu 1.1.0's new realm filtering hides all core
beans.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
