Let applications restrict which classes wicket-cdi injects - #1569
Open
pedrosans wants to merge 1 commit into
Open
Let applications restrict which classes wicket-cdi injects#1569pedrosans wants to merge 1 commit into
pedrosans wants to merge 1 commit into
Conversation
pedrosans
force-pushed
the
cdi-filter
branch
from
September 3, 2026 18:27
70f4b14 to
64d1d95
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1569 +/- ##
============================================
+ Coverage 61.85% 61.88% +0.03%
- Complexity 11180 11191 +11
============================================
Files 1245 1245
Lines 48220 48227 +7
Branches 6759 6759
============================================
+ Hits 29825 29845 +20
+ Misses 15694 15682 -12
+ Partials 2701 2700 -1 🚀 New features to boost your workflow:
|
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. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
pedrosans
force-pushed
the
cdi-filter
branch
from
September 8, 2026 22:26
64d1d95 to
fb70a76
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.