Let applications restrict which classes wicket-cdi injects - #1569
Open
pedrosans wants to merge 2 commits into
Open
Let applications restrict which classes wicket-cdi injects#1569pedrosans wants to merge 2 commits into
pedrosans wants to merge 2 commits into
Conversation
The package mixed both conventions, twelve files with CRLF against seven with LF. Editing a CRLF file and saving it with LF rewrote every line, so the real change ended up buried in whitespace. There is no .gitattributes and core.autocrlf is unset, but LF is the de facto convention in the tree: a 400 file sample under wicket-core/src/main/java is 349 LF to 51 CRLF. Convert the package to match it. Whitespace only, no content changes: git diff --ignore-cr-at-eol against the parent commit is empty. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
pedrosans
force-pushed
the
cdi-filter
branch
from
September 3, 2026 18:27
70f4b14 to
64d1d95
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #1569 +/- ##
============================================
+ Coverage 61.85% 61.87% +0.02%
- Complexity 11179 11189 +10
============================================
Files 1245 1245
Lines 48213 48226 +13
Branches 6760 6760
============================================
+ Hits 29822 29842 +20
+ Misses 15688 15682 -6
+ Partials 2703 2702 -1 🚀 New features to boost your workflow:
|
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.