Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hudson-dev] Supporting Java EE 7 (CDI 1.1) and later

Why not make it work with CDI by using CDI?

On Fri, Jan 23, 2015 at 5:50 PM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
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.

It might better to change the package and class names, though.


On Sat, Jan 24, 2015 at 9:24 AM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:
As one of the first steps, I made classes like the following just to satisfy unsatisfied CDI dependencies, assuming these methods are never called:

@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;
    }
}

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?

In addition, Bug 458002 must also be resolved to deploy Hudson on a Java EE 7 server with its default settings.


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).

(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.




_______________________________________________
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


Back to the top