After removing the POM's erroneous reference to ${payara.miro.maven.version} and executing the example using the instructions, the following error and stack trace is observed:
[2019-08-23T11:33:22.944-0500] [] [SEVERE] [] [org.glassfish.jersey.internal.Errors] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1566578002944] [levelValue: 1000] [[
Following issues have been detected:
WARNING: A resource model has ambiguous (sub-)resource method for HTTP method GET and input mime-types as defined by"@Consumes" and "@Produces" annotations at Java methods public abstract java.util.concurrent.CompletionStage fish.payara.examples.microprofile.restclient.HelloService.helloAsync(java.lang.String) and public abstract java.lang.String fish.payara.examples.microprofile.restclient.HelloService.hello(java.lang.String) at matching regular expression /([^/]+). These two methods produces and consumes exactly the same mime-types and therefore their invocation as a resource methods will always fail.
]]
[2019-08-23T11:33:22.945-0500] [] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1566578002945] [levelValue: 1000] [[
WebModule[/rest-client]StandardWrapper.Throwable
org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization.
[[FATAL] A resource model has ambiguous (sub-)resource method for HTTP method GET and input mime-types as defined by"@Consumes" and "@Produces" annotations at Java methods public abstract java.util.concurrent.CompletionStage fish.payara.examples.microprofile.restclient.HelloService.helloAsync(java.lang.String) and public abstract java.lang.String fish.payara.examples.microprofile.restclient.HelloService.hello(java.lang.String) at matching regular expression /([^/]+). These two methods produces and consumes exactly the same mime-types and therefore their invocation as a resource methods will always fail.; source='org.glassfish.jersey.server.model.RuntimeResource@4a5e0faf']
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:371)
at org.glassfish.jersey.server.ApplicationHandler.lambda$initialize$1(ApplicationHandler.java:293)
at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:232)
at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:292)
at org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.java:259)
at org.glassfish.jersey.servlet.WebComponent.(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:154)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:346)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1521)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1329)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5494)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5739)
at com.sun.enterprise.web.WebModule.start(WebModule.java:618)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:956)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:939)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:684)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1891)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1596)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:123)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:294)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:357)
at com.sun.enterprise.v3.server.ApplicationLifecycle.initialize(ApplicationLifecycle.java:535)
at fish.payara.deployment.admin.InitializeAllApplicationsCommand.execute(InitializeAllApplicationsCommand.java:75)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:557)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:553)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:552)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:583)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:575)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:574)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1483)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1865)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1741)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:172)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.run(CommandExecutorImpl.java:96)
at fish.payara.micro.impl.PayaraMicroImpl.bootStrap(PayaraMicroImpl.java:1051)
at fish.payara.micro.impl.PayaraMicroImpl.create(PayaraMicroImpl.java:210)
at fish.payara.micro.impl.PayaraMicroImpl.main(PayaraMicroImpl.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at fish.payara.micro.boot.loader.MainMethodRunner.run(MainMethodRunner.java:50)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:112)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:71)
at fish.payara.micro.boot.PayaraMicroLauncher.create(PayaraMicroLauncher.java:87)
at fish.payara.micro.boot.PayaraMicroLauncher.main(PayaraMicroLauncher.java:72)
at fish.payara.micro.PayaraMicro.main(PayaraMicro.java:397)
]]
I tried every version from 5.182 through 5.192 and all of them work except 5.192. I haven't been able to pinpoint the cause but I question if the MP REST Client interfaces should be discovered and validated by Jersey during application deployment. It's my belief that the JAX-RS annotated interfaces are being discovered and validated and made part of the application.
This is also demonstrated in the inclusion of configured client paths in the application WADL and output Payara Micro URLs on server start up. While this can't be seen in the examples when they work, they are easily visible in an application that accesses another application's resources remotely. The remote URLs are included in the local application's WADL. I did not see this behavior on 5.191 but do see this behavior on 5.192. I'm going to work on a reproduction case independent of this report on the existing example.
After removing the POM's erroneous reference to
${payara.miro.maven.version}and executing the example using the instructions, the following error and stack trace is observed:[2019-08-23T11:33:22.944-0500] [] [SEVERE] [] [org.glassfish.jersey.internal.Errors] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1566578002944] [levelValue: 1000] [[ Following issues have been detected: WARNING: A resource model has ambiguous (sub-)resource method for HTTP method GET and input mime-types as defined by"@Consumes" and "@Produces" annotations at Java methods public abstract java.util.concurrent.CompletionStage fish.payara.examples.microprofile.restclient.HelloService.helloAsync(java.lang.String) and public abstract java.lang.String fish.payara.examples.microprofile.restclient.HelloService.hello(java.lang.String) at matching regular expression /([^/]+). These two methods produces and consumes exactly the same mime-types and therefore their invocation as a resource methods will always fail. ]]
[2019-08-23T11:33:22.945-0500] [] [SEVERE] [] [javax.enterprise.web] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1566578002945] [levelValue: 1000] [[ WebModule[/rest-client]StandardWrapper.Throwable org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization. [[FATAL] A resource model has ambiguous (sub-)resource method for HTTP method GET and input mime-types as defined by"@Consumes" and "@Produces" annotations at Java methods public abstract java.util.concurrent.CompletionStage fish.payara.examples.microprofile.restclient.HelloService.helloAsync(java.lang.String) and public abstract java.lang.String fish.payara.examples.microprofile.restclient.HelloService.hello(java.lang.String) at matching regular expression /([^/]+). These two methods produces and consumes exactly the same mime-types and therefore their invocation as a resource methods will always fail.; source='org.glassfish.jersey.server.model.RuntimeResource@4a5e0faf'] at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:371) at org.glassfish.jersey.server.ApplicationHandler.lambda$initialize$1(ApplicationHandler.java:293) at org.glassfish.jersey.internal.Errors.process(Errors.java:292) at org.glassfish.jersey.internal.Errors.process(Errors.java:274) at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:232) at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:292) at org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.java:259)
at org.glassfish.jersey.servlet.WebComponent.(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:154)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:346)
at javax.servlet.GenericServlet.init(GenericServlet.java:244)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1521)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1329)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5494)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5739)
at com.sun.enterprise.web.WebModule.start(WebModule.java:618)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:956)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:939)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:684)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1891)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1596)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:107)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:123)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:294)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:357)
at com.sun.enterprise.v3.server.ApplicationLifecycle.initialize(ApplicationLifecycle.java:535)
at fish.payara.deployment.admin.InitializeAllApplicationsCommand.execute(InitializeAllApplicationsCommand.java:75)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:557)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:553)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:552)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:583)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:575)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:574)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1483)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1865)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1741)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.executeCommand(CommandExecutorImpl.java:172)
at com.sun.enterprise.admin.cli.embeddable.CommandExecutorImpl.run(CommandExecutorImpl.java:96)
at fish.payara.micro.impl.PayaraMicroImpl.bootStrap(PayaraMicroImpl.java:1051)
at fish.payara.micro.impl.PayaraMicroImpl.create(PayaraMicroImpl.java:210)
at fish.payara.micro.impl.PayaraMicroImpl.main(PayaraMicroImpl.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at fish.payara.micro.boot.loader.MainMethodRunner.run(MainMethodRunner.java:50)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:112)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:71)
at fish.payara.micro.boot.PayaraMicroLauncher.create(PayaraMicroLauncher.java:87)
at fish.payara.micro.boot.PayaraMicroLauncher.main(PayaraMicroLauncher.java:72)
at fish.payara.micro.PayaraMicro.main(PayaraMicro.java:397)
]]
I tried every version from 5.182 through 5.192 and all of them work except 5.192. I haven't been able to pinpoint the cause but I question if the MP REST Client interfaces should be discovered and validated by Jersey during application deployment. It's my belief that the JAX-RS annotated interfaces are being discovered and validated and made part of the application.
This is also demonstrated in the inclusion of configured client paths in the application WADL and output Payara Micro URLs on server start up. While this can't be seen in the examples when they work, they are easily visible in an application that accesses another application's resources remotely. The remote URLs are included in the local application's WADL. I did not see this behavior on 5.191 but do see this behavior on 5.192. I'm going to work on a reproduction case independent of this report on the existing example.