pedrosans opened a new pull request, #1569: URL: https://github.com/apache/wicket/pull/1569
CdiConfiguration now takes a Predicate<Class<?>> deciding whether a class is an injection candidate, and ComponentInjector, BehaviorInjector and SessionInjector consult it before entering CDI. The default accepts every class, so nothing changes unless an application opts in. Every Component and Behavior instantiation goes through NonContextual, which resolves the BeanManager twice, creates a CreationalContext and calls InjectionTarget#inject, even for the many framework classes that declare no injection point at all. The InjectionTarget is cached per class, so nothing is rescanned, but that surrounding work is repeated per instance. It is cheap on a bare Weld container, which registers no InjectionServices and goes straight to Weld's own injection. It need not be cheap on a Jakarta EE container, where the integrator registers an InjectionServices of its own and Weld calls aroundInject on every InjectionTarget#inject, whether or not the class has anything to inject. That hook is where the container performs @Resource, @PersistenceContext, @PersistenceUnit, @EJB and @WebServiceRef injection, and the SPI leaves it to the integrator whether to cache the metadata parsed there. An application whose components need no injection can now skip the call rather than pay for it once per component. A rejected class gets no CDI at all: no @Inject, none of the resource injection above, and no @PostConstruct on a Session. None of those are reported by InjectionTarget#getInjectionPoints, so a filter that rejects too much fails silently. Hence the filter is opt-in and the default accepts everything. wicket-cdi's own listeners inject themselves through NonContextual directly and are never filtered, and neither is the application, which CdiConfiguration#configure injects itself. -- 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]
