[jira] [Updated] (CXF-4973) Resource constructor with @PathParam always recieves the path param of the first call

["Antoine Reilles (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Reilles updated CXF-4973:
---------------------------------

    Description: 
If I define a service using a constructor for injecting path parameters, as described in [http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-DealingwithParameters], the service will always be intantiated by recieving the value of the path parameter that was obtained during the first invocation of the service. Injecting the {{UriInfo}} in the service allows to compare the constructor injected path parameter value with the one used in the service, showing the issue.

The attached war exhibits the issue:
{code}GET http://localhost/testconstructor/a/b/one{code}
returns {{OK: one}}, and prints in the logs:
{code}
Service Constructor called with: one
Service nameparam one
{code}
A subsequent call to
{code}http://localhost/testconstructor/a/b/two{code}
returns an HTTP 500 (since the code raises an exception), with value {{one!= two}}, and prints in the server logs:
{code}
Service Constructor called with: one
Service nameparam two
MyExceptionMapper: javax.ws.rs.WebApplicationException
{code}




  was:
If I define a service using a constructor for injecting path parameters, as described in [http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-DealingwithParameters], the service will always be intantiated by recieving the value of the path parameter that was obtained during the first invocation of the service. Injecting the {{monospaced}}UriInfo{{monospaced}} in the service allows to compare the constructor injected path parameter value with the one used in the service, showing the issue.

The attached war exhibits the issue:
{code}GET http://localhost/testconstructor/a/b/one{code}
returns {{monospaced}}OK: one{{monospaced}}, and prints in the logs:
{code}
Service Constructor called with: one
Service nameparam one
{code}
A subsequent call to
{code}http://localhost/testconstructor/a/b/two{code}
returns an HTTP 500 (since the code raises an exception), with value {{monospaced}}one!= two{{monospaced}}, and prints in the server logs:
{code}
Service Constructor called with: one
Service nameparam two
MyExceptionMapper: javax.ws.rs.WebApplicationException
{code}




    
> Resource constructor with @PathParam always recieves the path param of the first call
> -------------------------------------------------------------------------------------
>
>                 Key: CXF-4973
>                 URL: https://issues.apache.org/jira/browse/CXF-4973
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.6.7
>         Environment: tomee 1.6.0-SNAPSHOT
>            Reporter: Antoine Reilles
>
> If I define a service using a constructor for injecting path parameters, as described in [http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-DealingwithParameters], the service will always be intantiated by recieving the value of the path parameter that was obtained during the first invocation of the service. Injecting the {{UriInfo}} in the service allows to compare the constructor injected path parameter value with the one used in the service, showing the issue.
> The attached war exhibits the issue:
> {code}GET http://localhost/testconstructor/a/b/one{code}
> returns {{OK: one}}, and prints in the logs:
> {code}
> Service Constructor called with: one
> Service nameparam one
> {code}
> A subsequent call to
> {code}http://localhost/testconstructor/a/b/two{code}
> returns an HTTP 500 (since the code raises an exception), with value {{one!= two}}, and prints in the server logs:
> {code}
> Service Constructor called with: one
> Service nameparam two
> MyExceptionMapper: javax.ws.rs.WebApplicationException
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira