As Winston suggested, I want to start discussion about Java EE 7 server support (or CDI 1.1 support) in Hudson. The following test is my understanding of the current situation (mostly taken from my forum post).
(Basic assumption)
As far as I know, Hudson uses dependency injection based on Guice by
Google and does not use CDI that is now a standard part of Java EE (6 and later).
(No problem before Java EE 7)
Java EE 6 included CDI 1.0 but it is not automatically enabled if
beans.xml is not included, so Hudson is happy with any Java EE 6
servers.
(Problem with Java EE 7)
To resolve issues that many users forget to include beans.xml (I guess),
CDI 1.1 introduced bean discovery modes and CDI is automatically
enabled in the 'annotated' mode even if there is no beans.xml. At least
one (and the reference) CDI implementation, Weld by JBoss, tries to discover a bean that
can be injected to any method and field annotated with @Inject
even if it will not actually use CDI for injection, which causes conflicts
to the use of @Inject in Hudson.
(Workaround)
Most (or all) Java EE 7 servers has an option to disable the automatic
CDI when deploying an application. By disabling the automatic CDI,
Hudson can be deployed successfully on such servers. A problem is the
way to activate the option differs by servers.
(No simple resolution)
Although CDI 1.1 introduced bean discovery modes and one of which is
'none', CDI 1.0 implementations will not see the value and might enable
CDI by the existence of beans.xml contrary to the intent to disable it.
So including beans.xml is not an option to resolve this problem at all.
My proposal is to add some bean classes to Hudson that have producer methods solely for satisfying dependencies on the form. I believe the producer methods need not to do anything useful since Hudson does not actually use CDI. If those methods are known not to be called, they can just either return null or throw an exception always.