Jersey Unit Test: in memory container vs grizzly

I'm trying to get my head around unit testing in Jersey.

The classes that do not depend on Jersey directly can be unit tested using standard JUnit. This one is OK.

But there are also Jersey (or, should I say JAX-RS?) dependent classes. In order to test these (inlc. correctness of the annotations, serialization, status codes, etc.) Jersey provides "test framework" that contains base JerseyTest class.

This is also fine and understandable.

Then, however, the official documentation specifies several types of supported containers in which subclasses of JerseyTest can be executed.

It seems like these containers can be divided into two types:

1. Real containers
2. In-memory container

From my current (newbie) perspective, all type #1 containers provide the same functionality. Therefore, let's take Grizzly as type #1 representative.

Now, it is clear that in-memory container (which is not a real container at all) is faster than Grizzly. Therefore, I'd like to use this container in order to test Jersey dependent classes. But this statement from the official documentation confuses me:

This containers does not support servlet and other container dependent features, but it is a perfect choice for simple unit tests.

I tried to google for comparison of in-memory container with Grizzly, but did not find any definitive comparison. I also read this highly technical thread, but the downsides of in-memory container are still not clear to me.

In this respect, I have two questions:

1. What "servlet and other container dependent features" are (no need for a comprehensive list, but just general description)?
2. If I choose in-memory container, can I then encounter a situation of code that passes test, but fails in production (I will use Tomcat in production, if that matters)?

Thanks

What "servlet and other container dependent features" are (no need for a comprehensive list, but just general description)?

Say you need to use HttpServletRequest, ServletContext, etc. in your resources. Or if you are using serlvet filters or listeners that affect the Jersey application. These are servlet features.

Other "container features" just means any other features that are specific to that container you are using in production. For example, with Grizzly, you can inject a Grizzly specific Request object.

If I choose in-memory container, can I then encounter a situation of code that passes test, but fails in production (I will use Tomcat in production, if that matters)?

Mainly if you use items mentioned above.

See an example of where a servlet environment is required. Here, there was a Servlet Filter being used for security. So the filter needed to be configured in the test. And another example where HttpServletRequest is needed