Le 19 févr. 2016 21:54, "Shahim Essaid" <[email protected]> a écrit : > > 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? >
Contexts are singleton so they are accessible. CreationalContext instance depends the scope of the bean and bean instances are not controlled. > 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 :-) > > > There are some samples of a method scope. Sounds all you need linked with some interception to activate the scope. > > > Best, > > > Shahim > > > >
