简体   繁体   English

在发出请求时,JAX-RS“端点”的行为如何?

[英]How does an JAX-RS 'endpoint' behave when making a request?

There is something I am not sure I understand correctlty, therefore, I need help:) 有些事情我不确定我理解是否正确,因此,我需要帮助:)

I have seen this: example , 我见过这个: 例子

@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? 这是否意味着对于每个请求,转换为“endpoint”的类会创建一个单独的线程? Because, otherwise, the headers information would not be accurate... 因为,否则,标题信息将不准确...

Can you please indicate a (short:) ) resource, not JAX-WS specifications, where I can find info about this? 你能指出一个(短:))资源,而不是JAX-WS规范,在哪里可以找到关于这个的信息?

I can't think of a shorter and more direct resource than the JAX-RS 1.1 spec itself . 我想不出比JAX-RS 1.1规范本身更短更直接的资源。 It is clear about what you are asking : 你明白要问的是

JAX-RS provides facilities for obtaining and processing information about the application deployment context and the context of individual requests. JAX-RS提供了用于获取和处理有关应用程序部署上下文和各个请求的上下文的信息的工具。 (...) (......)

Context is specific to a particular request (...). 上下文特定于特定请求(...)。

May I add for completeness: that context information is obtained through the @Context annotation. 我可以添加完整性:上下文信息是通过@Context注释获得的。 As of resources, the context information is only available to the ones annotated with @Path (also called root resources ). 在资源方面,上下文信息仅适用于使用@Path注释的内容(也称为根资源 )。 Also, @Context can inject the following context types : Application , UriInfo , HttpHeaders , Request , SecurityContext and Providers . 此外, @Context可以注入以下上下文类型ApplicationUriInfoHttpHeadersRequestSecurityContextProviders

And about the lifecycle (request/thread management): 关于生命周期 (请求/线程管理):

3.1.1 Lifecycle and Environment 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. 实现可以提供其他资源类生命周期,指定这些的机制超出了本规范的范围。 Eg an implementation based on an inversion-of-control framework may support all of the lifecycle options provided by that framework. 例如,基于控制反转框架的实现可以支持该框架提供的所有生命周期选项。

The conclusion is: 结论是:

  • Each request is, by default, handled by a different resource instance; 默认情况下,每个请求由不同的资源实例处理;
  • The context is injected at request time (thus a different context per instance). 在请求时注入上下文(因此每个实例具有不同的上下文)。

Each specific implementation may change this lifecycle a bit, but the principles should be maintained (a context specific to each request). 每个特定实现可能会稍微改变此生命周期,但应保持原则(特定于每个请求的上下文)。

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实现都是基于Servlet的,因此我们可以安全地假设每个请求实例都转到不同的线程 - 因为servlet容器是每个请求的线程。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM