Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microprofile REST Client examples do not deploy on 5.192 #109

Open
edthorne opened this issue Aug 23, 2019 · 0 comments
Open

Microprofile REST Client examples do not deploy on 5.192 #109

edthorne opened this issue Aug 23, 2019 · 0 comments

Comments

@edthorne
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant