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

Romain Manni-Bucau resolved TOMEE-900.
--------------------------------------
       Resolution: Fixed
    Fix Version/s: 7.0.0-M1

It is likely fixed for 1.7 serie too but didnt test so just setting 7.x serie 
for now

> jax-rs resource constructor with @PathParam always recieves the path param of 
> the first call
> --------------------------------------------------------------------------------------------
>
>                 Key: TOMEE-900
>                 URL: https://issues.apache.org/jira/browse/TOMEE-900
>             Project: TomEE
>          Issue Type: Bug
>         Environment: tomee-1.6.0-SNAPSHOT from 20130417
>            Reporter: Antoine Reilles
>             Fix For: 7.0.0-M1
>
>         Attachments: testconstructor.war
>
>
> 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:
>     GET http://localhost/testconstructor/a/b/one
> returns "OK: one", and prints in the logs:
>     Service Constructor called with: one
>     Service nameparam one
> A subsequent call to
>     http://localhost/testconstructor/a/b/two
> returns an HTTP 500 (since the code raises an exception), with value "one!= 
> two", and prints in the server logs:
>     Service Constructor called with: one
>     Service nameparam two
>     MyExceptionMapper: javax.ws.rs.WebApplicationException
> The issue cannot be reproduced on a plain tomcat (tested with tomcat-7.0.39). 
> Please have a look at 
> [CXF-4973|https://issues.apache.org/jira/browse/CXF-4973] for an analysis of 
> the issue by the cxf folks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to