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.

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).