| Re: [hudson-dev] Supporting Java EE 7 (CDI 1.1) and later |
According to Oracle's definition, CDI (JSR 346) is a standard part of the Java EE 7: http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html even with the web profile.
Weld is well known as the reference implementation of CDI and used by several products but another implementation that conforms to JSR 346 can also be used instead, if any. Other DI-only implementation that can coexist with CDI may be OK as well. To use CDI or other DI technology is what each application chooses but CDI 1.1 (or Weld only?) is too strict about unsatisfied CDI dependencies in my opinion.
So if an application chooses not to use CDI, it can either just satisfy CDI dependencies without real implementations as I am trying to do now OR instruct users to disable CDI at deployment-time. I don't think runtime switching is a good idea. It would make QA complicated and could make the application less reliable.
Also note that GlassFish includes both Weld and HK2 as far as I know. Since HK2 requires its own annotations to activate it, they can coexist without conflicts, I think. Do you know any Guice update (or its plan) regarding conflict avoidance?
I think the future is upon is. My humble opinion is we need to find a CDI-compatible implementation that will work fine with Tomcat and Jetty (and I guess Glassfish for the diehards).
Editorial comment: Hudson can't continue to be a graveyard for old technologies.
Whatever we choose, thanks, Kaz, for digging into this!
On Fri, Jan 23, 2015 at 11:31 PM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
It would be a future option to rely on CDI entirely, but Hudson currently uses Guice for dependency injection (as far as I know) and it actually works now, so such a switch will require some rewrites. And CDI is not available on all Java web servers yet, for example, Tomcat and Jetty do not include it by default.
So I cannot tell whether such rewrites deserve to do or not.
On Sat, Jan 24, 2015 at 11:01 AM, Bob Foster <bobfoster@xxxxxxxxx> wrote:
Why not make it work with CDI by using CDI?
On Fri, Jan 23, 2015 at 5:50 PM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
_______________________________________________It might better to change the package and class names, though.I submitted a patch to satisfy all unsatisfied dependencies only on the form as https://git.eclipse.org/r/#/c/40294/The advantage of this approach would be it does not change any existing classes and all the producer methods are placed inside a small number of unused classes. In addtion to this patch, a rename of the @Named annotation of ExtensionLocator actually allowed me to deploy Hudson 3.2.2-SNAPSHOT on GlassFish 4.1 without changing any deployment options.
On Sat, Jan 24, 2015 at 9:24 AM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
In addition, Bug 458002 must also be resolved to deploy Hudson on a Java EE 7 server with its default settings.As one of the first steps, I made classes like the following just to satisfy unsatisfied CDI dependencies, assuming these methods are never called:Each producer method might throw an UnsupportedException instead of just returning null to indicate more clearly that it shall not be used. What do you think?
@Singleton
public class InjectionHelper {
@Produces
private Injector getInjector() {
return null;
}
@Produces
private SmoothieContainer getSmoothieContainer() {
return null;
}
@Produces
@Named("default")
private ExtensionLocator getDefaultExtensionLocator() {
return null;
}
@Produces
private List<ExtensionFinder> getExtensionFinders() {
return null;
}
@Produces
@Parameters
private Map<String, String> getParametersMap() {
return null;
}
}
On Fri, Jan 23, 2015 at 5:59 PM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
Oops, s/following test/following text/
On Fri, Jan 23, 2015 at 5:57 PM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
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.
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hudson-dev
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hudson-dev
_______________________________________________
hudson-dev mailing list
hudson-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hudson-dev
_______________________________________________ hudson-dev mailing list hudson-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/hudson-dev