Status: Resolved (View Workflow)
Affects Version/s: 2.0.1.Final
Fix Version/s: 2.0.2.Final
Similar Issues:Show 10 results
WELD-1084 Introduce class InterceptorBindingType WELD-819 Fix for WELD-812 introduced a performance regression to Weld WELD-1066 Introduce an optional "global enablement" mode WELD-1433 Introduce non-portable SPI mode WELD-136 Introduce SPI to allow us to determine the BDA for various entry points to WB WELD-1412 Introduce proper SPI for constructor interception of EE components WELD-521 Introduce a way to exclude classes or packages from scanning WELD-808 Performance drop after introducing observer checks WELD-135 Introduce InjectionServices as alternative way for EE container to inject dependencies WELD-597 Weld class should be easier to extend to introduce custom behavior, for example the ability to replace the ResourceLoader
There are multiple situations when an InjectionTarget is created by an extension for a class that does not match bean class requirements. For example:
- abstract classes (Solder)
- non-static inner classes (cdi-wicket)
- classes with no appropriate constructor
Creating an InjectionTarget for such a class is OK as long as it is only ever used for injecting existing instances, not for producing instances.
We should introduce an InjectionTarget implementation capable of doing this and also log a warning each time it is created. If the application attempts to call produce() on such InjectionTarget, the call should fail with exception.