RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.
Link: Added: This issue relates to JBPAPP-7768
Link: Added: This issue Cloned to JBPAPP-7771
Link: Added: This issue is related to JBPAPP-7859
Not yet fixed in RESTEasy trunk. If it gets in to 2.3.2 upgrade, will be done in ER4.
RESTEasy 2.3.2 release made it into the ER4 build. However I don't see the upstream JIRA as resolved. Weinan, can you comment if this issue was resolved in the 2.3.2 release?
Weinan, Was the pull request merged upstream? As this priority on this release was downgraded, do you want to delay cutting a new resteasy release or do you plan to cut a release now since the fix is available. Please check the cutoff dates with Shelly if you plan to cut the release or move the fix version to TBD EAP6
Docs QE Status: Removed: NEW
My PR has been rejected 7 month ago and marked as 'old stuff' by Bill:
So mark this issue as won't fix.
Sorry Weinen, but I don't agree with the resolution. I understand from project PoV, this is a bit older issue and branch, but from product PoV, we need to maintain it for long time (5+ years). I can't accept the reason 'old stuff' as enough for not to fix a such weird issue in our product. Is there any other way how we can handle a such situation? Can QE help you somehow with escalation?
Hi Pavel, Bill has rejected the PR for this.
Please create an issue on JIRA against Branch_2_3 and assign it to Bill and explain why we need it. If he could get the PR merged then we could have a new release for RESTEasy 2.3.x.
(In reply to Pavel Janousek from comment #12)
> Sorry Weinen, but I don't agree with the resolution. I understand from
> project PoV, this is a bit older issue and branch, but from product PoV, we
> need to maintain it for long time (5+ years). I can't accept the reason 'old
> stuff' as enough for not to fix a such weird issue in our product. Is there
> any other way how we can handle a such situation? Can QE help you somehow
> with escalation?
Hi Weinen, I understand what you are requesting, but we are testing the product and its issues are tracked in BZ. I'm not sure if it is correct way how to handle the issue now.
Based on Brian's comment on JIRA, what about to create new PR to current EAP-6.2 branch and we will see if it works? Moreover, all PRs should be against EAP plus WildFly as well, but it is a longer time I've sent some PR though.
All the PRs must go to Branch_2_3 branch RESTEasy. It's already the maintenance branch for EAP6.
Requesting clarification on owner, relevance, target since this bug
more than than two years old and less than POST state:
As Bill rejected the PR, this bug won't be fixed in Branch_2_3.
Created upstream JIRA as requested. The fix is so easy I do not see the reason why it should not be done. Upstream version 2.3.8 (branch Branch_2_3) is used for EAP only at this moment. If it will not be accepted upstream, it can be sent to our internal repo from which is build resteasy for EAP
PR prepared https://github.com/resteasy/Resteasy/pull/454
Bill Burke <email@example.com> updated the status of jira RESTEASY-1030 to Closed
It will be included in RESTEasy 2.3.9
Marking as a Known Issue for the 6.3.0 Release Notes.
Draft note added.
Making public for inclusion in 6.3.0 Release Notes.
The fix is not present because resteasy is still in version 2.3.8.Final-redhat-3 not 2.3.9.
Verified in EAP 6.4.0.DR9, org.jboss.resteasy.spi.ResteasyDeploymentTest.