JNDI Поиск кода причуд
Я видел несколько проблем, связанных с отсутствием ресурсов JNDI. На Websphere (я знаю, вы его не используете, но это полезно знать ...) у вас будут проблемы с
Context envCtx = (Context) initCtx.lookup("java:comp/env");
Session session = (Session)envCtx.lookup("mail/Session");
Что работает (на Websphere) это
Session session = (Session) initCtx.lookup("java:comp/env/mail/Session");
Из того, что вы написали в другом ответе, я понимаю, что это не ваша проблема - я оставляю это здесь для людей, которые сталкиваются с той же проблемой при других обстоятельствах позже.
Поиск ресурсов JNDI из самопорожденных потоков
Кроме того, доступ к ресурсам JNDI может зависеть от потока, ищущего ресурсы. Насколько я помню, потоки не очень хорошо определены в API сервлетов (или Java EE или связанных областях. Это может быть даже добровольно и явно не определено). Поэтому сервер не обязательно должен предоставлять ресурсы JNDI в потоках, которые вы создали сами (опять же, Websphere меня укусил, я не тестировал Tomcat6 в этом отношении, более ранние версии использовались для предоставления ресурсов JNDI всем потокам)
Вы написали, что ищете ресурсы JNDI из одного экземпляра. Если вы , в момент поиска ресурсов, изучите трассировку стека (либо в вашей IDE, сгенерировав исключение, либо связавшись с Thread.currentThread().getStacktrace()): есть ли Соединитель Tomcat в трассировке стека или один из методов собственного потока Thread () в корне трассировки стека ? Это ответит на вопрос, стоящий за вопросом Джека, если вы делаете поиск из класса Action. (см. ответ Джека)
Threads и call-environment часть вторая
Создайте новое действие Struts и вызовите оттуда свой код поиска JNDI, посмотрите, работает ли оно, если оно расположено как можно ближе к стойкам и в рамках обработки http-запроса. Если это работает здесь, продолжайте с шагами выше.
срок действия web.xml
Также, возможно, вы захотите взглянуть на определение схемы для web.xml, чтобы убедиться, что ваш resource-ref расположен правильно. Спецификация сервлета 2.4 доступна на jcp.org и должна быть достаточной для проверки, даже если tomcat реализует 2.5.
В конце концов, я считаю, что tomcat6 проверяет web.xml, так что вы, вероятно, уже нашли его в правильном положении. (Не могу вспомнить, так как мой редактор IDE жалуется, когда я ошибаюсь, мне нужно написать web.xml)
Параметры отладки Tomcat
Многие записи context.xml имеют атрибут debug. Хотя я считаю, что достаточно низких однозначных значений, я принял привычку добавлять 'debug = "99" к таким элементам, как "Context" или другим. Возможно, вы захотите узнать, приводит ли это к некоторым полезным записям в журнале.
Убедитесь, что это не путь к классу
Поскольку вы, похоже, коренным образом изменили среду, убедитесь, что у вас есть все необходимые библиотеки на борту - почтовый API состоит из нескольких jar-файлов. Загрузите новую копию и распакуйте все библиотеки в каталог $ CATALINA_HOME / lib. Вы можете убрать неиспользованный, когда он будет работать со всеми библиотеками там.
Относительно вашего вопроса о пути к классам :
Причина нахождения класса при помещении в $ CATALINA_HOME / lib заключается в том, что соединение выполняется сервером (помните - вы определили его в context.xml, который читается сервером для запуска приложения ), таким образом, jar должен быть на серверах classpath, а не только на приложениях (см. загрузчик классов tomcat HOWTO для получения дополнительной информации)
EDIT:
Относительно вашего частичного решения :
$ CATALINA_HOME / conf / context.xml содержит глобальные контекстные элементы «по умолчанию». Это не то место, где вы хотите, чтобы конфигурация вашего приложения была.
Стандартная позиция для tomcat находится либо в веб-приложении META-INF / context.xml, либо в файле xml (назван как вам угодно, заканчивающийся .xml) в $ CATALINA_HOME / conf / Catalina / localhost /. Более позднее решение на самом деле предпочтительнее в отношении META-INF / context.xml, потому что таким образом конфигурация не зависит от приложения и не перезаписывается при развертывании нового приложения.
Этот контекст обычно содержит дополнительные атрибуты, такие как docBase и path:
<Context docBase="/location/where/you/deployed/your/application" path="/app">
...
</Context>
Таким образом, ваше приложение доступно на http://servername:8080/app. При развертывании в каталоге $ CATALINA_HOME / webapps значение docBase может быть относительно веб-приложения. Будьте осторожны в отношении условий гонки: Tomcat автоматически развернет приложения в $ CATALINA_HOME / webapps и может создать файл контекста. Кроме того, удаление веб-приложения для развертывания нового может привести к тому, что tomcat удалит файл конфигурации xml.
Для этого - какой бы ни была ваша проблема: попробуйте, если ваше определение контекста / приложение работает, когда помещено в $ CATALINA_HOME / conf / Catalina / localhost / app.xml. У меня такое ощущение, что это что-то очень простое, где не хватает только последней информации, чтобы увидеть реальную проблему.