| Re: [hudson-dev] Supporting Java EE 7 (CDI 1.1) and later |
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).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.
(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.