On Fri, Feb 19, 2016 at 12:31 PM, Mark Struberg <[email protected]> wrote:
> 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. > > Hi Mark, Sure, no problem. I'm just sharing some general thoughts (the long part) to give some background for why I'm asking my questions. There is a specific issue that I need some hints about from the experts on this list. I'm copying it here: > 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. There is one additional issue that I didn't think about when I wrote my post. I'm assuming that the CDI specification doesn't require (or explicitly prohibits) that a contextual reference remember the context it was resolved to after the first invocation of that reference. If this is the case, I would be interested in understanding how to add this capability to the OWB implementation for my specific use case. In other words, I think that the contextual reference has to be created by the context, not the bean so the reference is a reference to "this type, form this context". Which OWB classes should I be looking at to give this a try, and is this even feasible with the current OWB implementation architecture? Best, Shahim > 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 > >
