вадякак можно обойти эту проблему? Как обычно .

Хранить можно где угодно. Главное, чтобы "где угодно" не попадало в контекст приложения.
Ещё можно развёртывать не war, а каталог - не по стандарту, но существенно сокращает время развёртывания и не удаляет то, что было записано внутри каталога приложения. Но и в этом случае оптимально выделять для хранения отдельный ресурс, т.к. пользовательские данные определённо не являются частью приложения.
Местоположение такого хранилища задаёт или параметр контекста или JNDI. В обоих случаях администратор сервера имеет возможность настройки хранилища адекватным образом.

Ни к одному из этих каталогов нельзя привязывать хранилище файлов.

вадятипа вызов идет src="pic/preview/pic.jpg" , фильтруется pic/preview/ и редиректится на c:/тополя/ля/ля?"Во многобукв" доке на контексты есть многобукав про docBase, который может смотреть куда угодно.

вадяэти много букв я понял как это будет место расположения всего сервера, куда и будет рзвертыватьмя .war, затирая всё староеКроме собственно приложения можно определить кучу других контекстов. В том числе - для статических ресурсов, куда никакие war-ы развёртываться не будут.

вадядай пример как это сделать Defining a context и как на такой ресурс сослаться для src="......""Для внешнего мира" имя ресурса определяется именем контекста: даёт контекст, который "будет известен" как /ctx1. Как указать контейнеру, что статические ресурсы этого контекста находятся в другом месте - по ссылке выше.

P.S. Имхо, лучше уходить от свалки в webapps и приучиться размещать описатели контекстов там, куда указывает Host xmlBase .
Этот вариант не будет затирать настройки, сделанные администратором сервера, при развёртывании новой версии приложения. Но требует, чтобы администратор произвёл такую настройку при первоначальном развёртывании вашего приложения.

вадятолько конкретного примера применения нет.Задаём параметр контекста и вычитываем его в init() сервлета.
Если не выносим описатели за пределы webapps, то примерно так:

Ответственность за то, чтобы в двух местах были указаны одинаковые значения - лежит на администраторе сервера.
В частном, но распространённом случае можно задать местоположение при помощи свойства: и тогда будет:
Имена параметра и свойства никак не связаны между собой - могут быть одинаковы, могут быть разными.

вадяпроблема именно в выносе за webappsОписатель (deployment descriptor) сильно не эквивалентен значению одного из параметров этого описателя (docBase).
За пределами webapps (независимо) может находиться любой из них.