是否有可能从RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext获取@PathParam或@QueryParam？

我的服务：是否有可能从RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext获取@PathParam或@QueryParam？

@POST 
public String setData(@QueryParam("id") Long is, MyObject payload) { 
... 
} 

or 

@POST 
public String setData(@PathParam("id") Long is, MyObject payload) { 
... 
}

我在服务器上拦截：

Object read(MessageBodyReaderContext context) throws IOException, WebApplicationException { 

Class mypayloadtype = context.getType; 

InputStream mypayloadinpustream = context.getInputStream(); 


Long myidparam = ???????? // how to get the query or path param here? 

}

编辑：是有点更具体：

我希望做的是抢XML并根据参数将其存储在单独的审计系统中。也许PreProcessInterceptor/PostProcessInterceptor是更好的选择？

当xml仍然可用于预处理时，获取参数的任何提示或替代方法？

米格尔

来源

2013-02-13 Miguel ZP

我并没有觉得你应该使用拦截器来进行身体反序列化;我认为这是通过JAX-RS“MessageBodyReader”子类完成的，并且不应该知道_other_参数。这就是主要的服务方法应该知道处理的内容。 – 2013-02-15 20:47:24

我编辑了这个问题，以明确为什么我想使用拦截器。 – 2013-02-20 08:17:23

我不上的话题，但我的专家看来，如果在MessageBodyReaderContext接口并不真正知道这是否是服务器或客户端上，所以不能暴露请求或者其参数/路径部分等。

所以据我所知这是不可能的。

如果你的代码都知道，它生活在休息通信的服务器端，也许你可以使用一个Servlet过滤器来存储请求在一个ThreadLocal，然后从那里访问它，而请求处理，有些类似于弹簧框架中的RequestContextFilter/RequestContextHolder？（然后，请求对象不知道服务注释的任何内容，而是必须从请求中手动提取信息，这意味着在两个地方有相同的信息，所以必须有更好的解决方案。。）

编辑：看一些例子后，我得到了模糊的感觉，如果你想读取输入流，以创建一个对象并添加路径参数给它，MessageBodyReaderInterceptor根本就不是要走的路。取而代之的是建立一个MessageBodyReader，它根据请求主体数据构造对象，然后将其传递到public String setData(@PathParam("id") Long is, MyObject payload)，假定此方法用与MessageBodyReader的@ConsumeMime注释相匹配的@Consumes进行注释。您可能在setData中设置从请求主体读取的对象上缺少的ID。一些与此相关的例子似乎在这里：How to get full REST request body using Jersey?（但泽西岛，而不是jBoss： - /）

但我不确定这是否适合你，我也觉得我完全高估了我的能力回答这个问题适当的，所以我希望有更多的知识有更好的解决方案。

来源

2013-02-13 18:12:29

感谢克莱门斯试图澄清这一点。我认为从@ServerInterceptor注释中可以知道拦截器在哪一侧被使用。在客户端阅读器拦截器的情况下，我期望始终只有0个查询/路径参数，因为只有有效负载被返回。 – 2013-02-14 09:09:49

拦截器肯定会在代码所在的哪一侧生效，但不是'MessageBodyReaderContext'对于服务器/客户端是不可知的，即使假设传入的上下文是'ServerMessageBodyReaderContext'也没有帮助，因为该类不允许也可以访问请求。我不得不承认，我不是JBoss专家（甚至不是新手），只是希望其他人出现并发出“我可以做得更好”的任何答案，但到目前为止这没有奏效，对不起。 – 2013-02-14 20:24:51

我今天偶然发现了同样的问题。我需要@PathParam S和@QueryParam S IN的read()方法，结束了这样的事情：

public class MyInterceptor implements PreProcessInterceptor, MessageBodyReaderInterceptor 
{ 
    private static ThreadLocal<UriInfo> uri = new ThreadLocal<UriInfo>(); 

    public ServerResponse preProcess(HttpRequest request, ResourceMethod method) 
    { 
     uri.set(request.getUri); 
     ... 
    } 

    public Object read(MessageBodyReaderContext context) 
    { 
     String param = uri.get().getPathParameters().getFirst("myidparam"); 
     ... 
    } 
}

虽然现在考虑这个问题的时候 - 我不是很确定，如果只是用PreProcessInterceptor/PostProcessInterceptor也会做我的（也许是你的）问题的诀窍。我明天再看一次。

来源

2013-02-21 20:52:00 carstor

真是个破解！也许PreProcessInterceptor/PostProcessInterceptor是更好的选择。然而，我不得不弄清楚如何从HttpRequest获取有效载荷而不干扰请求处理... – 2013-02-26 09:13:57

是否有可能从RestEASY MessageBodyReaderInterceptor中的MessageBodyReaderContext获取@PathParam或@QueryParam？

回答

相关问题