org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization. [[FATAL] No injection source found for a parameter of type public Custom2Resource RootResource.getCustom2(Custom2) at index 0.; source='ResourceMethod{httpMethod=null, consumedTypes=[], producedTypes=[], suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=class RootResource, handlerConstructors=[org.glassfish.jersey.server.model.HandlerConstructor@5d0a1059]}, definitionMethod=public Custom2Resource RootResource.getCustom2(Custom2), parameters=[Parameter [type=class Custom2, source=name, defaultValue=null]], responseType=class Custom2Resource}, nameBindings=[]}']

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • The issue occurs when migrating a Jersey 1.18.1 application to Jersey 2.12 that also includes "sub-resource" with custom type parameters in the locator. A showcase example is attached to demonstrate what is explained below. If I have {{Custom1}} with the following constructor: {code:java} public Custom1(String value) {} {code} and {{Custom1}} has an associated {{Custom1ReaderWriter}}. Then, {{Custom1}} can be used as follows to provide a "sub-resource": {code:java} @Path("custom1/{name}") public Custom1Resource getCustom1(@PathParam("name") Custom1 name) { return new Custom1Resource(name); } {code} as it seems that the above constructor is expected to create an instance of {{Custom1}} for the method invocation. However, if I have a {{Custom2}} with the following constructor: {code:java} public Custom2(String value1, String value2) {} {code} and {{Custom2}} has also an associated {{Custom2ReaderWriter}}. Then, trying to use {{Custom2}} for a "sub-resource" as: {code:java} @Path("custom2/{name}") public Custom2Resource getCustom2(@PathParam("name") Custom2 name) { return new Custom2Resource(name); } {code} leads to the following exception: {code} org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization. [[FATAL] No injection source found for a parameter of type public Custom2Resource RootResource.getCustom2(Custom2) at index 0.; source='ResourceMethod{httpMethod=null, consumedTypes=[], producedTypes=[], suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=class RootResource, handlerConstructors=[org.glassfish.jersey.server.model.HandlerConstructor@5d0a1059]}, definitionMethod=public Custom2Resource RootResource.getCustom2(Custom2), parameters=[Parameter [type=class Custom2, source=name, defaultValue=null]], responseType=class Custom2Resource}, nameBindings=[]}'] at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:467) at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163) at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285) at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:600) ... 17 more {code} Trying to understand this better, I added another constructor to {{Custom2}} as: {code:java} public Custom2(String value) {} {code} that internally creates the proper instance, the above exception is gone. So: - The above workaround may be (even with high cost of migration) applied to custom types. - The above workaround is not viable for external types as we have a number of "sub-resource" instantiations as: {code:java} @Path("address/{address}") public InetAddressSubResource getAddressResource(@PathParam("address") InetAddress address) { return new InetAddressSubResource(address); } {code} in which we are using an external type; e.g. {{java.net.InetAddress}} and we do not have control over them. - The question is that why the implementations of "message body workers" are not used for sub-resource method invocations? This was the behavior in Jersey 1.x as far as I can see. - The next question actually is that if this is by spec in JAX-RS 2.x? Or JAX-RS 2.x allows to use message body workers for sub-resource method invocation parameters?
    via by nobeh5,
  • The issue occurs when migrating a Jersey 1.18.1 application to Jersey 2.12 that also includes "sub-resource" with custom type parameters in the locator. A showcase example is attached to demonstrate what is explained below. If I have {{Custom1}} with the following constructor: {code:java} public Custom1(String value) {} {code} and {{Custom1}} has an associated {{Custom1ReaderWriter}}. Then, {{Custom1}} can be used as follows to provide a "sub-resource": {code:java} @Path("custom1/{name}") public Custom1Resource getCustom1(@PathParam("name") Custom1 name) { return new Custom1Resource(name); } {code} as it seems that the above constructor is expected to create an instance of {{Custom1}} for the method invocation. However, if I have a {{Custom2}} with the following constructor: {code:java} public Custom2(String value1, String value2) {} {code} and {{Custom2}} has also an associated {{Custom2ReaderWriter}}. Then, trying to use {{Custom2}} for a "sub-resource" as: {code:java} @Path("custom2/{name}") public Custom2Resource getCustom2(@PathParam("name") Custom2 name) { return new Custom2Resource(name); } {code} leads to the following exception: {code} org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization. [[FATAL] No injection source found for a parameter of type public Custom2Resource RootResource.getCustom2(Custom2) at index 0.; source='ResourceMethod{httpMethod=null, consumedTypes=[], producedTypes=[], suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=class RootResource, handlerConstructors=[org.glassfish.jersey.server.model.HandlerConstructor@5d0a1059]}, definitionMethod=public Custom2Resource RootResource.getCustom2(Custom2), parameters=[Parameter [type=class Custom2, source=name, defaultValue=null]], responseType=class Custom2Resource}, nameBindings=[]}'] at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:467) at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163) at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285) at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:600) ... 17 more {code} Trying to understand this better, I added another constructor to {{Custom2}} as: {code:java} public Custom2(String value) {} {code} that internally creates the proper instance, the above exception is gone. So: - The above workaround may be (even with high cost of migration) applied to custom types. - The above workaround is not viable for external types as we have a number of "sub-resource" instantiations as: {code:java} @Path("address/{address}") public InetAddressSubResource getAddressResource(@PathParam("address") InetAddress address) { return new InetAddressSubResource(address); } {code} in which we are using an external type; e.g. {{java.net.InetAddress}} and we do not have control over them. - The question is that why the implementations of "message body workers" are not used for sub-resource method invocations? This was the behavior in Jersey 1.x as far as I can see. - The next question actually is that if this is by spec in JAX-RS 2.x? Or JAX-RS 2.x allows to use message body workers for sub-resource method invocation parameters?
    via by nobeh5,
    • org.glassfish.jersey.server.model.ModelValidationException: Validation of the application resource model has failed during application initialization. [[FATAL] No injection source found for a parameter of type public Custom2Resource RootResource.getCustom2(Custom2) at index 0.; source='ResourceMethod{httpMethod=null, consumedTypes=[], producedTypes=[], suspended=false, suspendTimeout=0, suspendTimeoutUnit=MILLISECONDS, invocable=Invocable{handler=ClassBasedMethodHandler{handlerClass=class RootResource, handlerConstructors=[org.glassfish.jersey.server.model.HandlerConstructor@5d0a1059]}, definitionMethod=public Custom2Resource RootResource.getCustom2(Custom2), parameters=[Parameter [type=class Custom2, source=name, defaultValue=null]], responseType=class Custom2Resource}, nameBindings=[]}'] at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:467) at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:163) at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:323) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289) at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:320) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285) at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358) at javax.servlet.GenericServlet.init(GenericServlet.java:244) at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:600)

    Users with the same issue

    Unknown visitor2 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,
    25 more bugmates