Eclipse Community Forums: Hudson » What is injected to the SmoothiePluginStrategy constructor?

Help

Home

Home » Archived » Hudson » What is injected to the SmoothiePluginStrategy constructor?

Show: Today's Messages :: Show Polls :: Message Navigator

What is injected to the SmoothiePluginStrategy constructor? [message #1572720]

Mon, 19 January 2015 09:45

Kaz Nishimura

Messages: 89
Registered: December 2014

Member

I am trying to understand how Guice injection is working in Hudson. I now have a question what is injected to the 4th parameter of the org.hudsonci.inject.internal.plugin.SmoothiePluginStrategy constructor of type List<ExtensionFinder> and how. Can anyone describe it briefly or give me pointers?

Kaz Nishimura

Report message to a moderator

Re: What is injected to the SmoothiePluginStrategy constructor? [message #1572897 is a reply to message #1572720]

Mon, 19 January 2015 11:58

Stuart McCulloch

Messages: 22
Registered: July 2009

Junior Member

Is this in relation to https://git.eclipse.org/r/39810 ? If so then there's a known issue [1] with CDI 1.1 which shipped with JEE7 with annotation scanning on by default [2]. Basically it assumes that any class annotated with @javax.inject.Singleton is meant to be managed by CDI - even when the class is meant to be managed by a container internal to the application, as in this case. The issue is fixed in CDI 1.2 by removing JSR330 scopes from the list of annotations that infer a class should be managed by CDI.

There is a workaround for deploying onto CDI 1.1 which is to add a "beans.xml" in the WEB-INF directory which explicitly turns off CDI discovery for the application:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="none">
</beans>

1. https://issues.jboss.org/browse/CDI-377
2. https://blogs.oracle.com/theaquarium/entry/default_cdi_enablement_in_java

Report message to a moderator

Re: What is injected to the SmoothiePluginStrategy constructor? [message #1572924 is a reply to message #1572897]

Mon, 19 January 2015 12:15

Stuart McCulloch

Messages: 22
Registered: July 2009

Junior Member

PS. regarding your question about how List<ExtensionFinder> is populated, this is done by an extension on top of Guice called Sisu [1] which can provide collections of components (among other things) without the need to explicitly declare a binding for the collection in the injector. It uses the Guice SPI to scan the declared set of bindings, and fill in the missing dependencies. There is also a class called SezPozExtensionModule which uses a generated index [2] to scan for Hudson extension points and convert them to Guice bindings.

1. https://eclipse.org/sisu/
2. https://github.com/jglick/sezpoz/

Report message to a moderator

Re: What is injected to the SmoothiePluginStrategy constructor? [message #1573770 is a reply to message #1572897]

Mon, 19 January 2015 23:15

Kaz Nishimura

Messages: 89
Registered: December 2014

Member

Unfortunately, bean-discovery-mode is added in CDI 1.1, CDI 1.0 implementations will not see it and might enable bean discovery by the existence of beans.xml. I found no automatic way to effectively disable bean discovery both in CDI 1.1 and in 1.0. Apparently, this was a mistake in CDI 1.1, we must cope with it.

It is still possible to disable bean discovery manually in CDI 1.1 but it would be different with servers. You could instruct users to disable automatic CDI for Hudson on Java EE 7 servers until the problem is resolved. FYI, Jenkins does not have this problem and it could even look superior in deploying on Java EE 7 servers.

Kaz Nishimura

Report message to a moderator

Re: What is injected to the SmoothiePluginStrategy constructor? [message #1573797 is a reply to message #1572924]

Mon, 19 January 2015 23:36

Kaz Nishimura

Messages: 89
Registered: December 2014

Member

Thank you for the explanation. Weld is repoting unsatisfied dependencies for the List parameter randomly when refusing a Hudson deployment. A producer method or field should be OK to satisfy such dependencies even if CDI is not actually used but I couldn't make it discovered by CDI yet.

Updating the sisu-inject-bean dependency seems to resolve some unsatisfied dependencies but I couldn't resolve all just by it.

Kaz Nishimura

Report message to a moderator

Previous Topic:	GoogleTest (gtest) output xunit-Plugin
Next Topic:	Hudson on Java EE 7 (CDI 1.1)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Oct 07 00:06:09 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter