发出请求时,JAX-RS的“端点"如何表现? [英] How does an JAX-RS 'endpoint' behave when making a request?

查看:75
本文介绍了发出请求时,JAX-RS的“端点"如何表现?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我不确定我是否理解正确,因此,我需要帮助:)

There is something I am not sure I understand correctlty, therefore, I need help:)

我已经看到了:示例

@Path("/resource")
public class Resource {
    @Context
    private HttpHeaders headers;

    @GET
    public void get(@Context UriInfo uriInfo) {
       /* use headers or uriInfo variable here */
    }
}

这是否意味着对于每个请求,转换为端点"的类都会创建一个单独的线程?因为,否则,标头信息将不准确...

Does this mean that for each request the class that is transformed to 'endpoint' creates a separate thread? Because, otherwise, the headers information would not be accurate...

您能指出一个(short :)资源,而不是JAX-WS规范,我可以在其中找到有关此信息的信息吗?

Can you please indicate a (short:) ) resource, not JAX-WS specifications, where I can find info about this?

推荐答案

我想不出比您在问什么:

JAX-RS提供了用于获取和处理有关应用程序部署上下文和单个请求上下文的信息的工具. (...)

JAX-RS provides facilities for obtaining and processing information about the application deployment context and the context of individual requests. (...)

上下文特定于特定请求(...).

Context is specific to a particular request (...).

为完整性起见,我可以补充一下:上下文信息是通过@Context批注获得的.从资源开始,上下文信息仅可用于使用@Path注释的上下文信息(也称为根资源).另外,@Context可以注入以下上下文类型:UriInfoHttpHeadersRequestSecurityContextProviders.

May I add for completeness: that context information is obtained through the @Context annotation. As of resources, the context information is only available to the ones annotated with @Path (also called root resources). Also, @Context can inject the following context types: Application, UriInfo, HttpHeaders, Request, SecurityContext and Providers.

关于生命周期(请求/线程管理) ):

And about the lifecycle (request/thread management):

3.1.1生命周期和环境

默认情况下,为每个请求创建一个资源类实例 该资源.首先,调用构造函数, 然后注入所有请求的依赖项(上下文是这些依赖项之一),然后 调用适当的方法,最后 对象可用于垃圾收集.

By default a new resource class instance is created for each request to that resource. First the constructor is called, then any requested dependencies are injected (context is one of those dependencies), then the appropriate method is invoked and finally the object is made available for garbage collection.

实施可以 提供其他资源类生命周期,以及用于指定这些生命周期的机制 不在本规范范围之内.例如.一个实现 基于控制反转框架可能会支持所有 该框架提供的生命周期选项.

An implementation MAY offer other resource class lifecycles, mechanisms for specifying these are outside the scope of this specification. E.g. an implementation based on an inversion-of-control framework may support all of the lifecycle options provided by that framework.

结论是:

  • 默认情况下,每个请求都由不同的资源实例处理;
  • 上下文是在请求时注入的(因此每个实例具有不同的上下文).

每个特定的实现可能会稍微更改此生命周期,但应保留原则(特定于每个请求的上下文).

Each specific implementation may change this lifecycle a bit, but the principles should be maintained (a context specific to each request).

正如您所看到的,该规范也没有对线程管理进行任何说明.由于大多数JAX-RS实现都是基于Servlet的,因此我们可以肯定地假设每个请求实例都转到不同的线程-因为Servlet容器是每个请求的线程.

As you can see, also, the spec says nothing about thread management. Since most JAX-RS implementations are Servlet-based, we can assume with certain safety that the each request instance goes to a different thread - as servlet containers are thread per request.

这篇关于发出请求时,JAX-RS的“端点"如何表现?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆