4 Replies Latest reply on Jun 20, 2016 5:55 AM by Herve Ngounou

    How does weld manage custom scope/context?

    Herve Ngounou Newbie

      When we create a custom scope and its associated context, we can register them in weld via an Extension.

      For example:


      public classMyExtension implements Extension {

          void addScope(@Observes final BeforeBeanDiscovery bbd) {

              bbd.addScope(MyCustumScoped.class, true, false);



          void addContext(@Observes final AfterBeanDiscovery abd) {

              abd.addContext(new MyCustomContext());




      Does it mean that when we call


      the BeanManager always returns the same Context instance (the one registered with void addContext(@Observes final AfterBeanDiscovery abd))?


      If true, does it mean that we can have only one instance of a given context at the same time?


      Thanks you

        • 1. Re: How does weld manage custom scope/context?
          Martin Kouba Master

          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?
            Herve Ngounou Newbie

            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?
              Martin Kouba Master

              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?
                Herve Ngounou Newbie

                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



                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: