Implement features from CDI Alpha4 release#3332
Open
manovotn wants to merge 10 commits intoweld:masterfrom
Open
Implement features from CDI Alpha4 release#3332manovotn wants to merge 10 commits intoweld:masterfrom
manovotn wants to merge 10 commits intoweld:masterfrom
Conversation
Update `weld.api.version` to 7.0.Alpha5 and `cdi.tck.version` to 5.0.0.Alpha3. Add no-op stubs for new CDI 5.0 API methods to restore compilation: - `BeanAttributesConfigurator.eager(boolean)` - `BeanConfigurator.eager(boolean)` - `AfterDeploymentValidation.ensureAsyncHandlerExists()` - `BeanInfo.isEager()` - `StereotypeInfo.isEager()` - `SyntheticBeanBuilder.eager(boolean)`
Member
Author
|
The CI TCK failure is unfortunately correct in some artifacts are missing from the release, see also jakartaee/cdi#946 (comment). I ended up reverting TCKs to the previous Alpha version for now. |
When `Instance` is obtained programmatically via `BeanContainer.createInstance()` and no qualifiers are specified, `DynamicLookupInjectionPoint.getQualifiers()` now returns `@Default` instead of an empty set. This aligns with the CDI 5.0 spec clarification (issue weld#779) that `@Default` is implied when no qualifiers are selected.
b6d434d to
cab86ed
Compare
`@Registration(types = ...)` now supports `TypeLiteral` subclasses to specify parameterized registration types. For example, `@Registration(types = MyTypeLiteral.class)` where `MyTypeLiteral extends TypeLiteral<MyService<String>>` will match beans whose types include `MyService<String>`. Changes in `ExtensionPhaseRegistration`: - Resolve `TypeLiteral` subclasses to their actual type argument - Validate against raw `TypeLiteral` and type variables Changes in `ExtensionPhaseRegistrationAction`: - Accept `Set<Type>` instead of `Set<Class<?>>` - Bean matching: raw type comparison for `Class`, exact match for parameterized types - Observer matching: raw assignability for `Class`, type closure check for parameterized types
840adea to
8a551c7
Compare
Add `AsyncHandler` discovery and integration into the invoker
chain. When a method's return type or parameter type matches a
registered async handler, dependent bean cleanup is deferred until
the async operation completes.
Built-in `@ReturnType` handlers are provided for `CompletionStage`,
`CompletableFuture`, and `Flow.Publisher`.
Key changes:
- `AsyncHandlerRegistry` as a deployment-level `Service` in the
`ServiceRegistry`, shared across all BeanManagers
- `AsyncInvokerImpl` applies async handler's `transform()` with
deferred cleanup for both `@ReturnType` and `@ParameterType`
- `CleanupActions` deferred variants store the instance in a
ThreadLocal instead of running cleanup on success
- `AfterDeploymentValidation.ensureAsyncHandlerExists()` and
`InvokerValidation` support in the lite extension translator
The 5.0.0.Alpha3 release did not publish all artifacts correctly, causing dependency resolution failures for the TCK runner module.
`@ApplicationScoped` beans annotated with `@Eager` (or with a
stereotype declaring `@Eager`) are now eagerly initialized during
container startup, before the `Startup` event is fired. Eager beans
are collected during `addBean()` for efficient startup init.
Key changes:
- `ImmutableBeanAttributes`: new `eager` field and `isEager()`
- `BeanAttributesFactory` / `ExternalBeanAttributesFactory`: detect
and preserve `@Eager` on beans, producers, and extension-provided
`BeanAttributes`
- `StereotypeModel` / `MergedStereotypes`: support `@Eager` via
stereotypes, including inherited stereotypes
- `BeanAttributesConfiguratorImpl` / `BeanConfiguratorImpl`:
real `eager(boolean)` implementation
- `ForwardingBeanAttributes`: delegate `isEager()`
- `Validator`: `@Eager` on non-`@ApplicationScoped` is a
`DefinitionException`
- `BeanManagerImpl`: collect eager beans during `addBean()`
- `WeldStartup`: instantiate collected eager beans in
`endInitialization()` before the `Startup` event
- Lite extension translator: `BeanInfo.isEager()`,
`StereotypeInfo.isEager()`, and `SyntheticBeanBuilder.eager()`
Cleanup of invoker and lite extension translator modules to ensure all exceptions go through Logger interfaces instead of being thrown directly.
8a551c7 to
e80b31e
Compare
Added a test using a @singleton stereotype to verify eager initialization works for singleton beans.
b78f698 to
ed2e33f
Compare
Member
Author
|
Keeping it as draft a while longer as I also need to implement the synthetic injection points from the latest CDI API release. |
…ctions Bump Weld API to 7.0.Alpha6. Implement the new CDI 5.0 API for declaring and validating injection points on synthetic beans.
bb2362f to
e05d8ce
Compare
Member
Author
These are now implemented as well, moving out of draft state. |
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.
A work in progress in implementing latest parts of CDI API.