Разница между сеансами.getServletContext() и Session.getServletContext().getContext ("/SampleProject")

я чувствую, что ваш вопрос был немного неправильно понят и что у вас уже было базовое понимание API, т. е. когда веб-приложение устанавливает его crossContext="true" можно использовать getContext() чтобы получить доступ к контексту, который соответствует некоторому другому веб-приложению, развернутому на сервере.

getServletContext().getContext() equals NULL unless <Context crossContext="true">

насколько я понял, ваш вопрос на самом деле заключается в том, что в /SameWebApp почему

ServletContext context1 = session.getServletContext();
context1.setAttribute("contextAttribute", new Object());
ServletContext context2 = session.getServletContext().getContext("/SameWebApp");

System.out.println(context1.equals(context2)); // prints false, or 
System.out.println(context2.getAttribute("contextAttribute")); // prints null (at least they could have been clones)

всего одним словом, ответ- "безопасность". Представьте, если бы вы не могли гарантировать, что атрибут контекста "adminEmail" не был изменен зло веб-приложение, имеющее свой crossContext=true. Ваше приложение может потенциально помочь скомпрометировать себя, как только придет запрос "Забыли пароль"! :)

погружение в внутренности Tomcat

Tomcat 7 предоставляет class ApplicationContext implements ServletContext что возвращается из getContext("/context-root") as

    if (context.getCrossContext()) {
        // If crossContext is enabled, can always return the context
        return child.getServletContext();
    } else if (child == context) {
        // Can still return the current context
        return context.getServletContext();
    } else {
        // Nothing to return
        return (null);
    }

здесь context принадлежит текущему веб-приложению и child представляет другое веб-приложение. Но, подождите, что заставляет Tomcat называть это ребенок?

эти двое на самом деле не ApplicationContext но факты StandardContext класс implements Context но вместо конкретных вещей сервлета содержит определенные настройки конфигурации Tomcat для веб-приложения, такие как crossContext, hostname, mimeMappings и т. д. StandardContext.getParent() дает Container и, следовательно, он был упомянут как ребенок выше.

в любом случае, нас интересует случай, когда child == context - это правда, т. е. getContext() был вызван на "/SameWebApp". Вызов делегируется StandardContext.getServletContext() который был реализован, чтобы вернуть другой экземпляр of ApplicationContext.

вот почему атрибуты, которые вы установили в context1 не нашли в context2.

но подождите, есть еще кое-что. Почему StandardContext.getServletContext() вернуться как

return (context.getFacade());

экземпляр Tomcat в основном выполняет два типа Java код:

• контейнеров, и
• пользователь развернул

код контейнера является "доверенным" и иногда может потребоваться запуск с повышенными привилегиями. С другой стороны, код пользователя не является надежным и должен быть ограничен от компрометации внутренних компонентов Tomcat.

одна из вещей, которую Tomcat делает для достижения этого, всегда обертывает ApplicationContextFacade вокруг ApplicationContext (и, следовательно,StandardContext как хорошо). Итак, чтобы подытожить, что кажется, простой ServletContext реализация на самом деле StandardContext сопоставляется с ApplicationContext, который затем заворачивают в ApplicationContextFacade.

для получения дополнительной информации о том, как ApplicationContextFacade работает с использованием отражения в тандеме с Globals.IS_SECURITY_ENABLED и SecurityUtil.isPackageProtectionEnabled() настройки пожалуйста, взгляните на почему сервлеты получают доступ к Tomcat ApplicationContext через фасад на SO.

ссылки:
Исходный Код Tomcat 7 (Ссылка Для Скачивания)