Hi all,
I've been looking at CDI and OpenWebBeans with few usecases in mind. They
mostly depend on flexible context management, and there are no concrete
examples of the use cases yet, but I'm trying to understand my options.
You've seen few JIRA comments that are related to this but the following
goes beyond those issues.
An example will help understand why I'm looking into this. I would like to
take advantage of the CDI programming model but extend how contexts are
created and managed to be able to deal with certain real world situations.
For example, a @PersonScoped could be a scope for personal objects and
let's assume that there is only one context for for this scope that holds
all personal related objects. However, @OrgScoped is a scope for
organization beans but organizations are almost always hierarchical
(Company, branch, department, etc.). At runtime this hierarchical nature
can be represented as a tree or a DAG of @OrgScoped context instances each
with their own instantiation of @OrgScoped beans but with different values
or information in those instances. There are many other examples of
hierarchical contexts in the real world and the available information in
each context can be augmented with, or defaulted by, information from a
parent context without having to define custom beans or bean qualifiers for
the related contexts. The Bean type is exactly the same but there are
additional instances in other contexts that should be considered when
needed. There are also other types of beans in those contexts and when each
bean instance is looked at in a context, it should be considered in
relationship to other instances in that same context.
With the above example, I would like to possibly do the following in some
code that is running in the @PersonScoped context for a specific person
(contexts are identified per person just like sessions, conversations, etc.
are internally identified in the usual case), and all the instantiated
ancestor @OrgSScoped contexts that were previously instantiated at runtime
and assigned as parent contexts for this specific person. If this code has
the following injection point:
@Inject Instance<WorkInfo> workInfo;
and there is a bean:
@OrgScoped
class WorkInfo {}
and the code iterates over the instances, it should see a list of WorkInfo
instances starting from the direct @OrgScoped context as usual but then
also be able to get the instances from the parent contexts that were
explicitly managed at runtime. So, the code will see their WorkInfo
instances from their direct work context but then other instances from the
parent contexts.
I think this can be boiled down to having a method that returns a list of
contexts from BeanManager as in:
public List<Context> getContext(Class<? extends Annotation> scopeType);
and have the various CDI services be able to deal with this by going
through the list. The current behavior would be equivalent to only using
the first context on this list, if it is available.
I know this might sound strange but the CDI programming model is very
useful (more flexible domain modeling, injection, type resolution, etc.)
but the context model is not flexible enough. There are a lot of real world
situations that can be addressed with more flexible contexts rather than
with additional qualifiers and scopes. The organization example above can't
really be dealt with with more qualifiers and scopes. There is no limit to
the nesting of organizational structures and there is a lot of duplication
of information types in each nested context (i.e. same Bean but different
instance).
The above example is just a simplified version of my use case. I'm in the
biomedical domain and involved in ontology development, and data
integration and exchange. The ability to create runtime contexts of the
same scope, populate those contexts with the same type of data but from
different sources, and have those instances available for injection in a
controlled way (beyond the simple one context per scope) could be very
powerful. Think about all the identical medication information that exists
for you in different contexts (hospitals, clinics, etc.) but where the
different prescriptions are very contextual and can't be well understood
outside their own context. They are based on a specific visit, doctor, a
specific diagnosis, etc. all of which forms a single clinical context
instance but these instances should be accessible from other contexts for
validation, monitoring, reconciliation, etc. This is complicated but I'm
trying to explore the possibility of representing some of this as CDI
context instances (rather than qualifiers, etc.) with some additional APIs
to link contexts, and resolve injection points across these linked contexts
in an application specific way without having to give up on using the rest
of CDI.
What do I need to look at in the current OpenWebBeans implementation to
start to understand how I might be able to do this? Any hints will be
really appreciated, and at some point I'll be familiar enough with the
implement details to be able to help with other tasks :-)
Best,
Shahim
