0
votes

I have a Jersey-based web application (basically just REST services, no presentation) which I wish to deploy to a JBoss EAP 6.2 server. I first run into the problem described here, which I was able to solve using the accepted answer of the question. However, I then run into the following exception thrown by JBoss upon deploying my WAR:

16:24:10,142 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."search-rest.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."search-rest.war".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111] Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437 Normal scoped bean class org.glassfish.jersey.server.ResourceConfig is not proxyable because the type is final or it contains a final method public final org.glassfish.jersey.server.ResourceConfig org.glassfish.jersey.server.ResourceConfig.setClassLoader(java.lang.ClassLoader) - Managed Bean [class mjb44.searchapp.rest.Application] with qualifiers [@Default @Any]. at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:229) at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:180) at org.jboss.weld.util.Proxies.getUnproxyableTypesExceptionInt(Proxies.java:195) at org.jboss.weld.util.Proxies.getUnproxyableTypesException(Proxies.java:169) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:148) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:383) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:368) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379) at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:64) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] ... 3 more

16:24:10,350 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "search-rest.war" was rolled back with the following failure message: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"search-rest.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"search-rest.war\".WeldStartService: Failed to start service Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437 Normal scoped bean class org.glassfish.jersey.server.ResourceConfig is not proxyable because the type is final or it contains a final method public final org.glassfish.jersey.server.ResourceConfig org.glassfish.jersey.server.ResourceConfig.setClassLoader(java.lang.ClassLoader) - Managed Bean [class mjb44.searchapp.rest.Application] with qualifiers [@Default @Any]."}}

My Application is defined simply as:

import org.glassfish.jersey.server.ResourceConfig;
public class Application extends ResourceConfig {
    public Application () {
        register(mjb44.searchapp.filters.CORSFilter.class);
    }
}

… and so it is neither final nor contains any final methods. As such the problem obviously has to do with org.glassfish.jersey.server.ResourceConfig which however I cannot control. I also opened a discussion in JBoss forums here.

1

1 Answers

0
votes

Just for the record, the only reply I've received so far from the JBoss forums has been that:

I'm afraid the only JAX-RS implementation supported on EAP is RESTEasy.

… which seems weird as I guess if I provide the JAX-RS implementation in the WAR's WEB-INF/lib then any web container should be fine with that.