javax servlet过滤器与jersey过滤器 [英] javax servlet filter vs jersey filter

问题描述

我正计划编写一个servlet应用程序(旨在与OSGI一起部署)，并使用一些过滤器进行HTTP标头预处理.虽然最初决定使用javax.servlet过滤器实现，但在我看来，我实际上不知道为什么/何时选择使用它而不是Jersey ContainerRequestFilter. 当然，后者带有一些预先构建的过滤器，但可以说前者也是如此(例如，Cors过滤器). 因此，在选择使用哪个API时应考虑什么?在某些情况下，不应该使用某个方法来代替另一个方法吗?

I'm planning on writing a servlet application (meant for deployment with OSGI) and use some filters for HTTP header pre-processing. While originally settled on the javax.servlet filter implementation, it occured to me that I actually don't know why/when one would choose to use that vs the Jersey ContainerRequestFilter. Granted the latter comes with some pre-built filters, but arguably so does the former (eg Cors filter). Thus, what should be considered when choosing which API to use? Are there specific cases when one should not be used in favor of the other?

推荐答案

无论您做什么决定，您将使用基于javax.servlet的Filter实现，因为它是每个在Java EE中使用.

Whatever you decide, you will be using a javax.servlet based Filter implementation, since it is the base interface for every Filter you use in Java EE.

http://docs.oracle.com/javaee/6/api/javax/servlet/Filter.html

现在，Jersey附带了一个实现，该实现添加了一些功能(访问ContainerRequestContext或在Jersey应用程序中需要的任何内容).您的应用程序中已经在使用Jersey吗?然后去做，如果没有的话，我不会打扰(至少是先验的，并且没有进一步的信息)，只是去最简单的实现javax.servlet.Filter并将其直接放入我的web.xml

Now, Jersey comes with an implementation that adds some functionality (access to your ContainerRequestContext or whatever you would need inside your Jersey application). Are you using Jersey already in your application? Then go for it, if not I would not bother (at least a priori and without further information) and just go for the most simple possible implementation of javax.servlet.Filter and put it straight into my web.xml

这篇关于javax servlet过滤器与jersey过滤器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！