[GLASSFISH-20354] EJBException thrown in JAXRS resource that's also an EJB bean is sometimes consumed by CDI Created: 19/Apr/13  Updated: 23/Apr/13  Resolved: 23/Apr/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b86_RC2

Type: Bug Priority: Critical
Reporter: jan.supol Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-20385 Integrate Jersey 2.0-rc2 into the GF ... Resolved
Tags: 4_0-approved

 Description   

In a resource

@Stateless
@Path("/ssb")
public class StatelessRootResource {
	@Path("exception")
	@GET
	public String throwException() {
		throw new EJBException(new WebApplicationException(Status.CREATED));
	}
}

the EJBException should be unwrapped and the exception processed by JAXRS according to JAXRS Spec. However, this only happens in about 50% of deployments (tested 15times in a row). It seems that status 201 is returned only when JAXRS container is dealing with it. Sometimes, Status 500 returned and the exception is logged to server log. However, when

asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

,
Status 201 has been returned 10x in a row, no 500.



 Comments   
Comment by Jakub Podlesak [ 19/Apr/13 ]

As discussed offline with Jan, we need to make sure Jersey's EJB component provider takes precedence over the CDI one.

Comment by Jakub Podlesak [ 19/Apr/13 ]

set fixByVersion to b86. The fix should be delivered as part of Jersey 2.0-rc2

Comment by Jakub Podlesak [ 23/Apr/13 ]

This has already been fixed in Jersey 2.0-rc2, where EJB component provider takes precedence over the CDI one, so that also appropriated Exception mapper is configured all right.

Comment by Jakub Podlesak [ 23/Apr/13 ]

Added 4_0-review tag, required info for the review follow:

  • What is the impact on the customer of the bug?
  • If this was not fixed, customer would likely face a nasty non-deterministic behaviour (this bug shows up in 6 out of 10 cases)
    -This is clearly a regression
  • What is the cost/risk of fixing the bug?
  • The risk is quite low, and the bug was already fixed in Jersey 2.0-rc2
  • Is there an impact on documentation or message strings?
  • There is no such impact.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
  • JAX-RS/EJB integration tests
  • Which is the targeted build of 4.0 for this fix?
  • b86
Comment by Jakub Podlesak [ 23/Apr/13 ]

Fixed with Jersey 2.0-rc2 integration (https://java.net/jira/browse/GLASSFISH-20385)

Generated at Fri May 29 17:52:01 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.