Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@Context annotation declaration of HttpServletReqeuest object in parent reference is passing the first time API hit values to the resource always #5497

Open
Ganeshfair opened this issue Dec 11, 2023 · 3 comments

Comments

@Ganeshfair
Copy link

Hi Team,
We faced a peculiar issue in production and UAT environment, after JBoss server restarting the object reference of the first time hitting to the API, is being passed as input to further request hit to the same API in the same node. We debugged this issue till the jersey core libraries, the request processing context passed to the filters is proper as per the request hit (Stages.process(context, requestProcessingRoot, endpointRef)) whereas at the endpoint invocation line the context is not having the actual request context values instead the first API hit context is always getting passed for all the hits.
Please note the behavior is observed in the certain times when both nodes are running and we restart node by node in some scenarios, also this issue is not reproducible at every time it is randomly but frequently occurring.

Below is the API implementations:
  • The parent class which is a common file invoked for all the APIs implemented is having the @Inject HttpServeletRequest reference and used in child classes.
  • The first child resource class file which has only abstract methods is having @context annotated HttpServeletRequest reference object declared.
  • The actual resource file which implements the actual API methods, is not having any variable declared for HttpServeletRequest i.e. it is using the reference of first child resource class

ParentClass {
@Inject
protected HttpServletRequest request;
@Inject
protected HttpServletResponse response;
// Has common methods for preauthorize and validation methods
}

FirstChildClass {
@context protected HttpServletRequest request;
@context protected HttpServletResponse response;
// Has abstract method declaration and common factory methods for child classes
}

ActualResourceFile{
// No declaration for the HttpServletRequest

@GET
@ApiOperation(value = "Operation description", response = DetailsBean.class, responseContainer = "List")
@ApiResponses(value = {
		@ApiResponse(code = 200, message = "Successful retrieval of Details", response = DetailsBean.class,responseContainer="List")
}
		)
@MethodInfo(uri=”v1/listdetails”)
public Response fetchDetailsListing(

}

@jansupol
Copy link
Contributor

This issue looks tricky. While it can be a Jersey issue, I'd like to exclude possibilities that come from the Specific JBoss environment.

  • HttpServletRequest can be provided by multiple sources. One of them is one of the CDI/Weld jars that provides a CDI bean for the HttpServletRequest. Since @Inject is used, the CDI can be the injector instead of Jersey. Jersey supplies HttpServletRequest only by org.glassfish.jersey.containers:jersey-container-servlet-core. Do you have it in your environment?

  • Jersey supplies the HttpServletRequest provided by the servlet container, it does not have its own implementation, so from the actual injected instance it won't be clear whose bean is injected

  • From the intermittent nature of this issue it might be that sometimes there is some other provider than usual.

  • Jersey sets the HttpServletRequest in Request Scope so your issue should not apply from the quick look at the code.

  • When you change @Inject to @Context, does it help?

@Ganeshfair
Copy link
Author

@jansupol Thanks for the response... PFB my clarifications on this issue.

  1. Yes, we have org.glassfish.jersey.containers:jersey-container-servlet-core in our library path. Also HttpServletRequest is part of javax.servlet:javax.servlet-api and tomcat.servlet-api jars, I believe jersey uses the javax.servlet-api for injecting.

  2. Not tried modifying the @Inject to @context as the file this Inject done is a common file for all our APIs, so don't want to touch that point. But added the local variables for http servlet and response in the ActualResourceFile.class as below, after that the issue is not observed yet and keep monitoring.
    @context HttpServletRequest request;
    @context HttpServletResponse response;

  3. But wanted to understand how jersey injects and sets the scope of request processing context, also the actual cause of the issue that why the first API hit request context is always used. Is there Appserver level dependency, we using Jboss.

Thanks in advance... !!!

@jansupol
Copy link
Contributor

You can observe Jersey setting the supplier for injection in the WebComponent class.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants