Sling Adapters cache overly eager

you can give it a try with org.apache.sling.servlet-helpers 1.2.1-SNAPSHOT - if it solves the problem i can do a release.

workaround may be to split the unit tests in multiple ones, and making sure each one contains only one adaptTo call from the request for the same type.

@Stefan Seifert - Reported this at https://issues.apache.org/jira/browse/SLING-8804?

is there a reasonable way around this in the interim? Is the only way to have 2 AemContexts?

You’re not going crazy, there is indeed no way to create an issue there. You should instead log the issue in the Apache Sling Jira tracker.

Thanks, Stefan - am I going crazy, or is there no way to log Issues on ? I don't see the Issues option at all next to the “Code” tab (and I am logged in)

you're right, this is puzzling for simple testing use cases like in your example.

please note that the Adaptable interface does not define whether the impl behind it should cache exceptions or not.

lot's of implementations e.g. the most Resource implementations extend SlingAdaptable which always applies a caching of the results.

adapting from SlingHttpServletRequest is a special case - in the Sling Engine it is one of the few places which does not extend SlingAdaptable and thus does not cache the results. however, the mock implementation of SlingHttpServletRequest used in the mocks extends from SlingAdaptable an thus does the caching as well.

we might remove this caching from the mocked SlingHttpServletRequest to be as close to sling as possible - but if you adapt from resources you will still have the same problem (same behavior as in a running instance).

maybe you want to create a SLING ticket and/or a PR on https://github.com/apache/sling-org-apache-sling-servlet-helpers