[jboss-jira] [JBoss JIRA] (WFWIP-313) [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions

[Ronald Sigal (Jira)]

    [ https://issues.redhat.com/browse/WFWIP-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058141#comment-14058141 ] 

Ronald Sigal commented on WFWIP-313:
------------------------------------

Hi [~pkremens],

Yeah, that old pull request was a straightforward port from RESTEasy 4.x to 3.x, and it assumes the presence of MicroProfile Config and Smallrye Config. Making MP Config optional complicates things. I've got a ResteasyConfig class now that tests for the presence of the related jars so that things won't blow up:
{code}
   public ResteasyConfig()
   {
      try
      {
         Class.forName("org.eclipse.microprofile.config.spi.ConfigSource");
         Class.forName("org.jboss.resteasy.microprofile.config.ServletConfigSourceImpl");
         config = ResteasyConfigProvider.getConfig();
      }
      catch (Throwable e)
      {
         // Leave config == null.
      }
   }
{code}
So ResteasyConfigProvider.getConfig() won't get called unless the necessary classes are available.

I ran part of the RESTEasy testsuite, including the tests in org.jboss.resteasy.test.microprofile.config, after stripping the microprofile and wildrye stuff out of standalone.xml, and it passed.

I think I'll write a unit test that verifies that RESTEasy can run in the absence of the Config jars.

-Ron

> [EAP7-1386] Cannot deploy simple jax-rs application to server without microprofile extenstions
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFWIP-313
>                 URL: https://issues.redhat.com/browse/WFWIP-313
>             Project: WildFly WIP
>          Issue Type: Quality Risk
>            Reporter: Petr Kremensky
>            Assignee: Ronald Sigal
>            Priority: Major
>
> This one is probably caused by a fact that https://github.com/resteasy/Resteasy/pull/2250 was submitted a long time before the "MicroProfile Config will be available to EAP only when installing the MicroProfile expansion pack" was introduces. I just want to be sure that we're on a same page here and my understanding that this is a valid use case for EAP7-1386 is correct. If so, we might include similar use case into test plan to cover this.
> *Reproduce*
> Update the standalone.xml configuration file inside the WildFly server - remove all microprofile extensions/subsystems from it, and deploy a simple Jax-rs application - e.g. https://github.com/wildfly/quickstart/tree/master/helloworld-rs
> * WildFly 19.0.0.Final with default RESTEasy (3.11.0.Final)
> No issues with deployment.
> * WildFly 19.0.0.Final with RESTEasy 3.10.0-SNAPSHOT from https://github.com/resteasy/Resteasy/pull/2250 (7f10848)
> {noformat}
> 07:55:08,542 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 68) MSC000001: Failed to start service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-rs.war".undertow-deployment: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
>     at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
>     at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
>     at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
>     at java.lang.Thread.run(Thread.java:748)
>     at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
>     at org.eclipse.microprofile.config.spi.ConfigProviderResolver.loadSpi(ConfigProviderResolver.java:125)
>     at org.eclipse.microprofile.config.spi.ConfigProviderResolver.instance(ConfigProviderResolver.java:110)
>     at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:105)
>     at org.jboss.resteasy.microprofile.config.ResteasyConfigProvider.getConfig(ResteasyConfigProvider.java:11)
>     at org.jboss.resteasy.plugins.server.servlet.ConfigurationBootstrap.getParameter(ConfigurationBootstrap.java:353)
>     at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:136)
>     at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:42)
>     at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>     at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>     at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>     at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
>     at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
>     at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
>     at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
>     at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
>     at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
>     at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
>     at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
>     at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
>     ... 8 more
> 07:55:08,546 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "helloworld-rs.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
>     Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> 07:55:08,547 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "helloworld-rs.war" was rolled back with the following failure message: 
> {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-rs.war\".undertow-deployment" => "java.lang.IllegalStateException: No ConfigProviderResolver implementation found!
>     Caused by: java.lang.IllegalStateException: No ConfigProviderResolver implementation found!"}}
> {noformat}
> Please let me know in case that my expectations about this use case are wrong.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)