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

Setting the system property just caused NPE instead.

But strangely, if I try to open Hudson before it is fully up and ready, I can see the Hudson dashboard even on WileFly 8.2.0.Final with Java 7.  It could be related to initialization timing, IMO.

On Thu, Mar 19, 2015 at 11:11 AM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:

I searched for similar problems on the net.  Almost all the answers suggest to set system property com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager to true.  I will try it and see if it resolves the exception.  If it works fine, I will next try to set it at run time in Hudson.

2015/03/19 4:49 "Winston Prakash" <winston.prakash@xxxxxxxxx>:
Hi Kaz,

Everything seems to work fine on Glassfish 4.1. But one of our QA Engineers, Latha Amujuri, reported the following.
She tried it on WildFly (JBoss 8.2.0) and it did not work. Can you please take a look

-->

I just tried Wildfly 8.2.0 with JDK 1.8.0_40 with an existing Hudson home folder from 3.2.0. The main Hudson page does not load with the following exception:
I saw the same exception with Glassfish 4.1 as well but the main page loaded and it did not seem to affect any functionality.
java.lang.RuntimeException: javax.naming.NameNotFoundException: com.sun.jersey.config/CDIExtension -- service jboss.naming.context.java."com.sun.jersey.config".CDIExtension
com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:174)
com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:573)
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:605)
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:213)
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
org.hudsonci.rest.server.internal.jersey.RestServlet.init(RestServlet.java:113)
javax.servlet.GenericServlet.init(GenericServlet.java:244)
org.hudsonci.servlets.internal.ServletRegistrationFilterAdapter.init(ServletRegistrationFilterAdapter.java:96)
hudson.util.PluginServletFilter.init(PluginServletFilter.java:57)
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:111)
org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:85)
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:97)
io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:79)
io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:81)
hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:47)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.authentication.rememberme.RememberMeAuthenticationFilter.doFilter(RememberMeAuthenticationFilter.java:139)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:199)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:73)
hudson.security.HudsonFilter.doFilter(HudsonFilter.java:156)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:70)
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

-->

- Winston
Getting back on this track after a while.

I merged both commits and created a build. I also tested on two servers

GlassFish Server Open Source Edition 3.1.2.2   which I assume is EE 6

GlassFish Server Open Source Edition 4.1  which I assume is EE 7

Both seems to work fine. I will request our QA engineers to test on other servers (may be WildFly). 

http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html

Kaz, can you please tell us which server you tested, so we can create a matrix of tested servers.

- Winston

This one should resolve a bean name conflict (two beans named "default") that prevent Hudson from being deployed with Weld.

On Thu, Feb 19, 2015 at 7:12 AM, Winston Prakash <winston.prakash@xxxxxxxxx> wrote:
Hi Kaz,

Can you please give me the list of reviews (for Java EE 7 support) that are alive now. I saw you abandoning some. Just want to make sure I'm picking up the right ones.

- Winston

Hi Kaz,

In the community meeting we discussed about Hudson 3.3.0 release. The major theme of this release would be

- Java EE 7 support
- Moving Core to JDK 7 source API (dropping support for JDK 6 and below)
- Improving stability and performance

The development will continue until May with Release Candidate around last week of May, targeting the release around end of June, 2015. Few weeks are required to get the release approval from Eclipse Foundation.

Let us know if your work on Java EE 7 support can make it by then.

Thanks,

Winston

I learned unknown annotations are silently ignored if not available on the classpath as Stuart described, so we won't need to include any new jars.  It should be OK to just add dependency on cdi-api with scope 'provided' so that we can use CDI annotations only at compile-time.  I hope I can make a new patch in a few days.

2015/01/29 2:39 "Winston Prakash" <winston.prakash@xxxxxxxxx>:
Hi Kaz,

I have created this wiki page (just cut and paste some info from this e-mail). Can you please update it with all the findings and detail the solution we are going to use.

We have to get approval from Eclipse to add any new jar we bundle. So list the new jars that will be included in the war.

Thanks for all the work.

- Winston

Just FYI, I got an error from Weld even for org.hudsonci.service.internal.ServiceSupport.setHudson that it has unsatisfied dependency.  As you can see, class ServiceSupport has no annotations, just its method setHudson has @Inject.

Accoding to the CDI 1.1 spec, in the default 'annotated' bean discovery mode, ServiceSupport should not be discovered as a bean since it has no annotations.  So it appears that Weld is trying to process all @Inject annotations even for classes that have no bean defining annotations, as long as they have constructors without parameters, with which they are considered as managed beans.  It is unsolicited in my opinion, but it actually works as such.

If we try to resolve this issue without CDI compatibility, we will have to use Guice-equivalent of javax.inject.Inject, if any.


On Wed, Jan 28, 2015 at 9:38 AM, Kaz Nishimura <kazssym@xxxxxxxxx> wrote:

Thank you for the description.  I had believed annotations must be on the classpath if not provided by the container.

2015/01/28 9:26 "Stuart McCulloch" <mcculls@xxxxxxxxx>:

On Wednesday, 28 January 2015 at 00:22, Kaz Nishimura wrote:

If we ship Hudson with a cdi-api jar, compatibility with Java EE 5 servers will not be a problem, I believe.

I wouldn’t ship it with the cdi-api jar, instead make the dependency scope provided as the web container would be expected to provide it. That way the helper will activate on CDI capable web containers, and will be ignore elsewhere.

On the other hand, if we ship Hudson with the cdi-api 1.1 jar, does it break compatibility with Java EE 6?  I hope it doesn't but I am not a Java expert, so I chose to depend on the latest official release of CDI 1.0 API, cdi-api 1.0-SP4 for the moment.

FYI, as far as I know, any cdi-api jars just contain annotations (and necessary classes and interfaces, if any) without any CDI implementation.

2015/01/28 2:04 "Stuart McCulloch" <mcculls@xxxxxxxxx>:
On Tuesday, 27 January 2015 at 16:53, Winston Prakash wrote:
Hi Kaz/Sturat/Bob,

Let me try to re-iterate and understand the situation.

Hudson works in EE containers 5.x and below because there is no CDI. It also works in EE 6 because CDI is not enabled by default. However DI works in Hudson because Guice used in Hudson properly takes care of DI annotations (@Inject etc).

In EE7 CDI is enabled. Since CDI finds DI annotations in the code, it thinks it service is required. However, since it finds the wrong Injection Helpers (Specified as a Singleton), which is really meant for Guice, it throws error.

Three suggestions so far:

1. Add some dummy implementation for CDI Injection Helpers, so CDI will be happy, though it does nothing. But still Guice takes care of the  DI annotations

2. Change all javax.inject.Singleton to com.google.inject.Singleton. Since CDI will not understand this annotation, it will not try to incorrectly use the Injection Helpers and throw exception. However, Guice understands this annotation and works a

_______________________________________________
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