https://issues.jboss.org/browse/CDI-127 I have written up a proposal for how to add support for enums: ================================================ Notes ------- Enums are somewhat different to normal classes, as Java guarantees that any instances are singletons. Therefore we cannot treat them as classes. Furthermore, do we want to support them as beans, allowing them to be injected? Differences are: * No callback on instantiation, when do we inject? * Shared between deployments as singletons, how do we handle dependent scoped injections? * We do not control instantiation, cannot perform constructor injection Proposal ------------ We should support enums as non-contextual objects, performing field and method injection only. Enums should be assumed to be injected only after the application is fully initialized for portability. If an enum is on a shared classloader, any injections should correctly resolve to the deployment of the calling context. In other words, if a shared library or installed library has an enum A: enum A { FOO, BAR; @Inject B b; String getName() { return b.name; } } where B is a class defined in the shared library @ApplicationScoped class B { String name; } Then assuming that the name has been set to Pete in deployment 1, and Marius in deployment 2, when the enum A is used in deployment 1, the method getName() should return Pete, and in deployment 2 it should return Marius. ================================================ In my opinion, it's fairly obvious that supporting only field and method injection for enums makes sense, as does injecting them at application startup. This proposal also won't allow you to inject enum instances into other beans (this seems to go against the point of enums to me). How we handle enums in shared libraries (as the instances are shared between all apps then) is tricker, and the only way I can see to handle this is to a) say this results in non-portable behavior - punt on it b) require that the container can bridge to the correct calling context I believe it's possible to implement (b) in a non-pathological fashion, but would love to hear from Stuart, Siva, and the OWB team on how this would work for JBoss AS, GlassFIsh etc. Thoughts? Pete _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

On 21 Jun 2011, at 14:29, George Gastaldi wrote: > I think that what Brian needs is just allowing enum classes to be scanned and called on @Observes ProcessAnnotatedType. > IMHO, enums could be called, but they should be vetoed per spec (as you suggested before). > > Also, I have a bad feeling on allowing @Inject into enums as they can lead to non-expected behavior by allowing enum behavior to be changed, but it would be nice to hear another possible scenarios. This is possible today, I don't think allowing @Inject changes this at all. > > 2011/6/21 Pete Muir <pmuir(a)redhat.com&gt; > https://issues.jboss.org/browse/CDI-127 > > I have written up a proposal for how to add support for enums: > > ================================================ > > Notes > ------- > > Enums are somewhat different to normal classes, as Java guarantees that any instances are singletons. Therefore we cannot treat them as classes. Furthermore, do we want to support them as beans, allowing them to be injected? > > Differences are: > > * No callback on instantiation, when do we inject? > * Shared between deployments as singletons, how do we handle dependent scoped injections? > * We do not control instantiation, cannot perform constructor injection > > > Proposal > ------------ > > We should support enums as non-contextual objects, performing field and method injection only. Enums should be assumed to be injected only after the application is fully initialized for portability. > > If an enum is on a shared classloader, any injections should correctly resolve to the deployment of the calling context. In other words, if a shared library or installed library has an enum A: > > enum A { > > FOO, BAR; > > @Inject B b; > > String getName() { > return b.name; > } > } > > where B is a class defined in the shared library > > @ApplicationScoped > class B { > > String name; > } > > Then assuming that the name has been set to Pete in deployment 1, and Marius in deployment 2, when the enum A is used in deployment 1, the method getName() should return Pete, and in deployment 2 it should return Marius. > > ================================================ > > In my opinion, it's fairly obvious that supporting only field and method injection for enums makes sense, as does injecting them at application startup. This proposal also won't allow you to inject enum instances into other beans (this seems to go against the point of enums to me). > > How we handle enums in shared libraries (as the instances are shared between all apps then) is tricker, and the only way I can see to handle this is to > > a) say this results in non-portable behavior - punt on it > b) require that the container can bridge to the correct calling context > > I believe it's possible to implement (b) in a non-pathological fashion, but would love to hear from Stuart, Siva, and the OWB team on how this would work for JBoss AS, GlassFIsh etc. > > Thoughts? > > Pete > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev