[cdi-dev] CDI-127: Support for Enums

George Gastaldi gegastaldi at gmail.com
Tue Jun 21 09:29:44 EDT 2011


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.

2011/6/21 Pete Muir <pmuir at redhat.com>

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20110621/33f71231/attachment.html 


More information about the cdi-dev mailing list