If a build compatible extension adds a custom scope via MetaAnnotations#addScope, there will be exactly one context object of the given context class in the container if I read the JavaDoc correctly. However, there seems to be no way to extract this unique instance from the container once its running, except via BeanContainer#getContext and that only works if the context object I want is immediately active after instantiation and also happens to be the unique active context object for its scope.
This makes it surprisingly hard to define a new scope and context that can be programmatically activated and deactivated, like the RequestScope can.
In CDI full, this would be easy with a portable extension, because then I actually add the context objects themselves, not just a context class, and I could just store them in some field in the Extension and extract them later by injecting the Extension somewhere. In CDI Lite however, I would have to do a non-zero amount of shenanigans, e.g.
- I could make the constructor store a reference to the new instance in some static variable somewhere and hope nobody except the container will ever ever ever call that constructor. This introduces fragile global state and makes it impossible to have multiple containers running in parallel (for unit testing say).
- Or I could have the context active immediately after instantiation, call
getContext(MyScope.class) and store the object in some @Singleton bean by listening to a start up event and then immediately deactivate the context until it is truly needed. It is probably semantically wrong to have to scope start out as active if the scope should be programmatically activated and deactivated. Also, this is simply impossible if I ever need to context classes for the same scope. Deactivating the context may accidentally trigger @MyScope scoped beans that listen to a @BeforeDestroyed event.
It's probably possible to find better workarounds with even more shenanigans, but that seems unnecessarily hard. Has this simply been overlooked or is it by design not (easily) possible in CDI Lite?
If a build compatible extension adds a custom scope via
MetaAnnotations#addScope, there will be exactly one context object of the given context class in the container if I read the JavaDoc correctly. However, there seems to be no way to extract this unique instance from the container once its running, except viaBeanContainer#getContextand that only works if the context object I want is immediately active after instantiation and also happens to be the unique active context object for its scope.This makes it surprisingly hard to define a new scope and context that can be programmatically activated and deactivated, like the RequestScope can.
In CDI full, this would be easy with a portable extension, because then I actually add the context objects themselves, not just a context class, and I could just store them in some field in the Extension and extract them later by injecting the Extension somewhere. In CDI Lite however, I would have to do a non-zero amount of shenanigans, e.g.
getContext(MyScope.class)and store the object in some@Singletonbean by listening to a start up event and then immediately deactivate the context until it is truly needed. It is probably semantically wrong to have to scope start out as active if the scope should be programmatically activated and deactivated. Also, this is simply impossible if I ever need to context classes for the same scope. Deactivating the context may accidentally trigger@MyScopescoped beans that listen to a@BeforeDestroyedevent.It's probably possible to find better workarounds with even more shenanigans, but that seems unnecessarily hard. Has this simply been overlooked or is it by design not (easily) possible in CDI Lite?