| Hudson on Java EE 7 (CDI 1.1) [message #1573925] |
Tue, 20 January 2015 01:23  |
 Kaz Nishimura
Messages: 89
Registered: December 2014 |
Member |
|
|
To make the discussion clearer, I made a new topic.
(Basic knowledge)
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.
(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 ad CDI 1.1)
To resolve issues that many users forget to include beans.xml (I guess), CDI 1.1 have introduced bean discovery modes and CDI is automatically enabled in the 'annotated' mode even if there is no beans.xml. At least one 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 be actually injected by CDI, 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 automatic resolution yet)
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 contrary to the intent to disable it by the existence of beans.xml. So including beans.xml is not an option to resolve this problem at all.
(Question)
What should we do for future Hudson releases? I would like to deploy Hudson with no workaround. How do you think?
Kaz Nishimura
[Updated on: Wed, 21 January 2015 07:20] Report message to a moderator |
|
|
| Re: Hudson on Java EE 7 (CDI 1.1) [message #1573950 is a reply to message #1573925] |
Tue, 20 January 2015 01:43  |
Kaz Nishimura
Messages: 89
Registered: December 2014 |
Member |
|
|
One example of the unsatisfied dependencies is @Inject public void setHudson(final Hudson hudson) of class org.hudsonci.service.internal.ServiceSupport. It requires an injectable Hudson object by CDI, but class Hudson has no constructor annotated with @Inject and there is no producer method or field. As the Hudson object is apparently a singleton object, specifying a producer method or field would be adequate in my opinion but I have failed to add one.
One of the issues that make things complex is Weld reports only one type of unsatisfied dependencies randomly at once. If I make a change to resolve an unsatisfied dependency, it requires several times of failed deployment to check if the change actually has resolved it.
Kaz Nishimura
|
|
|
Powered by
FUDForum. Page generated in 0.05579 seconds
] 
Search
Help
Register
Login
Home
