Hi, I just created https://issues.apache.org/jira/browse/WICKET-7202
please have a look and let me know what you think about this. Its quite some text, but I also added our FastCdiComponentInjector as example. The immediate performance bottleneck manifests as lock contention inside Weld while InjectionTarget.inject() is executed. The underlying trigger is that wicket-cdi unconditionally invokes non-contextual CDI injection for every Component and Behavior, including classes without injection points and this "stalls" the whole process or even saturates the injection registry at some point (simplyfied spoken). If this is good from you I would try to have it applied on wicket itself then. Best, KB ----- Ursprüngliche Mail ----- > Von: "Emond Papegaaij" > An: "dev" <[email protected]> > Gesendet: Mittwoch, 2. September 2026 09:40:16 > Betreff: Re: Wicket 10 EE complience > I think we indeed forgot to bump the version and we should do so. The > changes are not that big and these versions should have aligned from the > start. > > @Korbinian Bachl > If you could file that as a Jira issue and open a pull request with the > suggested changes, that would be great. Contributions like that are always > welcome! > > Emond > > > Op wo 2 sep 2026 om 08:39 schreef Korbinian Bachl < > [email protected]>: > >> 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
