-
1. Re: How does weld manage custom scope/context?
mkouba Jun 15, 2016 2:11 AM (in response to hngounou)Hi Herve,
you could register multiple context instances per scope. But, only one may be active with respect to the current thread (if more than one contexts are active Weld throws IllegalStateException).
-
2. Re: How does weld manage custom scope/context?
hngounou Jun 17, 2016 10:00 AM (in response to mkouba)Thanks for you answer.
I want more control on my custom scope. Espacially, I want be able to explicitly store business instance (as singleton scope) from a class A in my context and then latter, in an onther classe B, retireve the data stored in my context.
So I have added two methods in my context, putBean() and getBean() (each business instance stored like this is stored as a singleton, so I use its class to retrieve it).
Such CDI usage is it conceivable?
Here is an example of the getBean() method:
-
3. Re: How does weld manage custom scope/context?
mkouba Jun 20, 2016 3:19 AM (in response to hngounou)Why exactly do you need this
putBean()
method? Have you considered using the built-in application context and producer methods? -
4. Re: How does weld manage custom scope/context?
hngounou Jun 20, 2016 5:55 AM (in response to mkouba)In fact, I want to developp a procucer/consumer framework, where each producer and each consumer work in its own thread.
Producers and consumers are uncoupled.
A producer produce data (pojo) and don't know any thing about consumers, it just produces data on specific subjects it is registerd to.
A Consumer don't know any thing about producers, it just consumes data published on subjects it subscribe to .
I plug CDI in my code at compile time, using pluggable annotation processor.
In the business code (which use my procucer/consumer framework), a producer class is annotated with @Producer
A consumer class is annotated with @Consumer and data class with @Data.
At compile time, I generate under the wood a CDI decorator class for each producer class, for each data class and for each consummer class.
All producer decorator generated have a scope: @ProducerScoped (remember, producer -so corresponding decorator too- run in its own thread).
Data produced has the same scope as its producer (data decorator is declared with scope @ProducerScoped).
Data is simple pojo uncoupled with its producer but, in order to be sent to consumers, it need to know its sending subject, its sending priority (error data must be sent before info data), the number of consumer allowed to read it as data can be used as signal to notify a single or severals or all consumer(s) ( 'sending end' data must be read by all concerned consumers).
As data is uncoupled with its producer which has those informations, under the wood, those needed informations are retrieved by Data decorator in context associated to @ProducerScoped scope.
So data decorator need first to retrieve its producer decorator (to call the relevant @Produces methods).
But data decorator just know that its producer decorator (as all the other producer decorators) implements Producer interface and has @Producer qualifier. So the following injection
@Inject
@Producer
Producer source
is ambigious, isn't it?
So to resolve this ambiguity, I want to be able to use the context of my custom scope as a container.
Indeed, I know that in my custom scope there is only one producer (as there is only one producer by thread) so I can store in the context of my custom scope this producer with a putBean methode defined in my context class like this: