Nice idea IMHO! One additional CDI-related observation from a production project:
We had to wrap Wicket's CDI injector with a lightweight pre-check which first determines whether a Wicket object (Component, Panel, Behavior, etc.) actually contains any CDI injection points before invoking CDI/Weld at all. Without this optimization, the generic Wicket injection mechanism effectively asks CDI to process every created component, even if there is nothing to inject. On complex pages this can easily result in hundreds or even thousands of unnecessary CDI injection attempts. This became a real scalability issue for us with Weld on Open Liberty. Under concurrent load, the large number of parallel injection requests caused heavy internal lock contention and, in our case, could effectively end up in a throughput collapse. So independently of the CDI 3 vs. CDI 4 question, it may be worth considering whether Wicket's CDI integration should avoid calling the CDI container at all when the target object has no injection points. If you need more details about this I'm happy to share it :) (text above was translated using AI) Best, KB ----- Ursprüngliche Mail ----- > Von: "Maxim Solodovnik" > An: "dev" <[email protected]> > Gesendet: Mittwoch, 2. September 2026 07:23:31 > Betreff: Wicket 10 EE complience > Hello All, > > Due to Wicket 10 is based at servlets 6.0 I'm assuming it should be > EE10 compatible > BUT according to https://jakarta.ee/release/10/ EE10 must have CDI 4.0 > > wicket-10 has CDI 3.0 and weld 4.0 is it on purpose? :) > > The question arise due to I have updated `wicketstuff-10` to jetty > 12.1 > https://github.com/wicketstuff/core/commit/e29e13abced816beaed2cc76cdb7d5d2e64db8dc > > And observing Weld/CDI issues while trying to prepare similar PR for wicket > > -- > Best regards, > Maxim
