Hi Shahim! Plz give me a bit to read through the long post. Currently busy with some other work but hope to get to it tonight or tomorrow morning.
txs and LieGrue, strub > Am 18.02.2016 um 20:58 schrieb Shahim Essaid <[email protected]>: > > 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
