4 Replies Latest reply on May 3, 2018 11:34 AM by ljnelson

    ApplicationScoped and synthetic beans

    ljnelson

      If I want to have a bean created that is scoped in a singleton (little-"s") way, there is no point to having it be @ApplicationScoped, right, since by the specification it cannot be intercepted or decorated?

       

      In other words, for a producer method (for example) that wishes to produce a singleton (little-"s"), it should @Produces @Singleton instead of @Produces @ApplicationScoped, right?

       

      Are there any reasons why I'd want to use @ApplicationScoped in such a use case?

       

      Thanks,

      Best,

      Laird

        • 1. Re: ApplicationScoped and synthetic beans
          manovotn

          Not sure what you mean by saying singleton (little-"s")? Is it the general programming pattern you are referring to?

           

          ljnelson  wrote:

           

          If I want to have a bean created that is scoped in a singleton (little-"s") way, there is no point to having it be @ApplicationScoped, right, since by the specification it cannot be intercepted or decorated?

          @ApplicationScoped can be intercepted or decorated if that's an ordinary bean backed by java class. If we are talking producers, then there is InterceptionFactory (CDI 2.0).

           

          ljnelson  wrote:

          In other words, for a producer method (for example) that wishes to produce a singleton (little-"s"), it should @Produces @Singleton instead of @Produces @ApplicationScoped, right?

          First of all - I am going to assume you are talking about EJB Singleton here (not CDI @Singleton).

          If that's the case, then both would work most of the times; they both fill the role of sole instance in your application. Each of them just provide some additional capability or two.

          Even if you use EJB's @Singleton, CDI will still pick that bean up and turn in into a CDI bean as well (and BTW it will be @ApplicationScoped from CDI point of view), hence in that case you get best of both worlds.

          The question is, if you even need it to be an EJB bean? EJB's @Singleton gives you the ability to (from the top of my head) have eager initialization, manage EJB timers, invoke asynchronous methods, remotely invoke methods and probably more.

          • 2. Re: ApplicationScoped and synthetic beans
            mkouba

            Well, there are few other reasons why to use application context. E.g. client proxies may help with circular dependencies, in Weld normal-scoped beans are instantiated lazily (i.e. an instance is not created until a client proxy method is invoked), client proxies may be passivated (serialized), even when the bean itself may not be... Last but not least @Singleton is not a bean defining annotation. Oh, and I forgot that application context is AlterableContext which means that you can destroy an @ApplicationScoped bean and it's recreated once needed again (this would not work without proxies).

            • 3. Re: ApplicationScoped and synthetic beans
              ljnelson

              manovotn  wrote:

               

              Not sure what you mean by saying singleton (little-"s")? Is it the general programming pattern you are referring to?

               

              Yes.

               

              @ApplicationScoped can be intercepted or decorated if that's an ordinary bean backed by java class. If we are talking producers, then there is InterceptionFactory (CDI 2.0).

               

              Thanks; that helps.

               

              ljnelson   wrote:

              In other words, for a producer method (for example) that wishes to produce a singleton (little-"s"), it should @Produces @Singleton instead of @Produces @ApplicationScoped, right?

              First of all - I am going to assume you are talking about EJB Singleton here (not CDI @Singleton).

              No, javax.inject.Singleton.

               

              Best,

              Laird

              • 4. Re: ApplicationScoped and synthetic beans
                ljnelson

                mkouba  wrote:

                 

                Well, there are few other reasons why to use application context. E.g. client proxies may help with circular dependencies, in Weld normal-scoped beans are instantiated lazily (i.e. an instance is not created until a client proxy method is invoked), client proxies may be passivated (serialized), even when the bean itself may not be... Last but not least @Singleton is not a bean defining annotation. Oh, and I forgot that application context is AlterableContext which means that you can destroy an @ApplicationScoped bean and it's recreated once needed again (this would not work without proxies).

                Thank you; this is exactly what I'm looking for.

                 

                Best,

                Laird