Хорошая новость. ушёл читать changelog

Хорошая новость!

Особенно aliasing. Поправьте если не так, но я могу сделать каталог с фотами, которые заливаются через приложение, но он не будет стираться при undeploy и может храниться в любом каталоге файловой системы? Только что закончил писать велосипед с котнроллером, который сливал клиенту jpeg фотки из такого каталога.

Если кто знает как сделать это уже сейчас на Spring/Tomcat6 одними конфигами, буду благодарен. Естественно только отображение, не аплоад )

разве он не месяц назад вышел ?

симлинк не подходит?

После deploy постоянно обновлять симлинк? Нашел два решения. Одно - велосипед с сервлетом, который выдает все что надо просто через OutputStream. Проблема - надо еще чтобы срабатывал кеш браузера, скоро разберусь, сделаю.

Второе - велосипед с дополнительным приложением, которое устанавливается раз и навсегда. Не нравится подсознательно. А ты симлинк делал для аватарок?

И еще, а есть гарантия что томкат его не затрет потом с утреца?

>реализовано обнаружение и предотвращение утечек памяти в веб-приложениях

Развенчиваем мифы о GC в общем и Java в частности.

то была бета.
правда я не уверен, что это - уже релиз...

>Развенчиваем мифы о GC в общем и Java в частности.

И тебя вылечат.

Его теперь можно считать полноценным Application server'ом или ещё нет?

Неужто во всех прошлых темах не насосался?

А ты кто? Я тебя знаю?

Он и не собирается. Он сервлет контейнер, был и будет. Его AS будут использовать возможно просто как своей компонент. Сравнение с Glassfish непонятно. И с термином «веб-сервер» лучше идти к PHPшникам

>В последнее время палочку эстафеты перехватил проект GlassFish, но, несмотря на это, Tomcat не собирается отставать.

Внутри Глассфиша кстати слегка модифицированный томкат.

> Второе - велосипед с дополнительным приложением, которое устанавливается раз и навсегда. Не нравится подсознательно. А ты симлинк делал для аватарок?

Да. Но war не кладу, а выкладываю просто развернутое приложение. По этому tomcat ничего и не стирает

> Внутри Глассфиша кстати слегка модифицированный томкат.

Внутри третьего вроде полностью своя реализация

http://www.linux.org.ru/server.jsp
Apache Tomcat 6

реализовано обнаружение и предотвращение утечек памяти в веб-приложениях;

Может в 7 исправлена ошибка PermGenMemory?

Спасибо

Это разве ошибка томката? Это же вроде фича JVM и лечится (по крайней мере на jboss, который с томкатом внутри) разрешением выгрузки классов и еще несколькими ключиками java.

Могу предложить менее переносимое, но относительно безгеморройное решение. Если Tomcat «прикрыт» легковесным веб-сервером типа lighttpd или nginx, или даже обычным Apache, то можно проставлять HTTP-заголовок «X-Sendfile» с путем к файлу (зависит от конкретного сервера, уточняйте), и httpd/lighttpd/nginx/etc. отдаст файл самостоятельно. Увы, сервлета-контроллера это не исключает, но весь кодинг будет занимать пару строк.

> Его теперь можно считать полноценным Application server'ом или ещё нет?

Нет.

>> реализовано обнаружение и предотвращение утечек памяти в веб-приложениях;

Может в 7 исправлена ошибка PermGenMemory?

PermGen это ошибка в приложении. Сам Томкат этим не болеет, но болеют приложения что деплоятся под него. PermGen ловится если остаются ресурсы, которые не закрыты к примеру.

ИЗ новости:

«Проект Apache Tomcat анонсировал выход версии 7.0.0 — первой версии, поддерживающей спецификации Java EE 6»

а можно хоть одну ссылку о том, что веб-контейнер Tomcat собирается стать полноценным АппСервером и поддерживать Java EE 6?

> а можно хоть одну ссылку о том, что веб-контейнер Tomcat собирается стать полноценным АппСервером и поддерживать Java EE 6?

О реализации полного стека Java EE речь не идет. В новости подразумевалось только то подмножество Java EE, реализацией которого всегда являлся Tomcat, а именно Java Servlet и JavaServer Pages.

Я посчитал, что тем читателям, которые находятся в теме, это должно быть очевидно.

> первой версии, поддерживающей спецификации Java EE 6.

это не совсем верно. поддержка спеки означает, что приложение проходит тесты совместимости на эту спеку. JavaEE 6 не ограничивается сервлетами и JSP, потому Tomcat никогда не будет поддерживать спеку JavaEE 6.

GlassFish 3 поддерживает спеку. JBoss 6 анонсирован, что будет совместим.

Дальше у JavaEE 6 есть Web Profile - урезанная версия для контейнеров... но даже ее Tomcat не собирается поддерживать. Jetty - уже заявила, что сделает... а вот Tomcat забил.

Так что не стоит вводить в заблуждение людей вписывая в одно предложение Tomcat и JavaEE 6 ;)

нинак) мне пришлось в свое время писать фильтр для аплоада/показа).

В glassfish 3 к счастью есть из коробки.

нет, это только сервлет контейнер как и раньше

это не ошибка томката, а ошибка Вашего приложения/библиотек, что оно не освобождает классы.

Не-а. permgen это именно фича redeploy приложения, что-то связано с classloader. Можно на rsdn.ru почитать, там были хорошие объяснения и ссылки. На самом деле не критично - на production приложение заливается редко и такой проблемы там нет.

совершенно верно. К слову, надеюсь, что glassfish v3 станет промышленным стандартом на смену томкату. Все таки надоело доставлять функциональность спрингом. А по скорости деплоя/работы приложения glassfish не медленнее томката, afaik

Мне помогали такие настройки:
JAVA_OPTS=" -XX:+CMSClassUnloadingEnabled XX:+CMSPermGenSweepingEnabled"
Пермгены практически исчезли

>> Он и не собирается. Он сервлет контейнер, был и будет.

Java EE 6 определяет т.н. web-profile для серверов приложений. Так что в принципе в терминах JEE6 он - сервер приложений

>> Может в 7 исправлена ошибка PermGenMemory?

Это лечится настройкой JVM и кошерным использованием возможностей Java внутри сервера приложений (запреты на работу с потоками, файлами, сокетами и т.д. ) Правда, возможно, не во всех серверах приложений

кошерным использованием возможностей Java внутри сервера приложений (запреты на работу с потоками, файлами, сокетами и т.д. )

запретить кучу вкусностей - очень кошерно, да.

> палочку эстафеты

>> Он и не собирается. Он сервлет контейнер, был и будет.

Java EE 6 определяет т.н. web-profile для серверов приложений. Так что в принципе в терминах JEE6 он - сервер приложений

только Tomcat не собирается поддерживать JavaEE 6 web profile, потому «в принципе в терминах JEE6 он НЕ сервер приложений» ;)

Хорошая новость

Нужно опробовать новую версию

>Не-а. permgen это именно фича redeploy приложения, что-то связано с classloader. Можно на rsdn.ru почитать, там были хорошие объяснения и ссылки. На самом деле не критично - на production приложение заливается редко и такой проблемы там нет.

Проблема в том, что в Java в силу разных причин и кривых реализаций библиотек очень легко зацепить классы так, что они не выгрузятся.

Например, через ThreadLocal в статическом поле класса. Пока треды, для которых есть значение в этом ThreadLocal не прибьёшь, эта конструкция не будет собрана GC.

и не только, еще sun jvm не выгружает нативный код откомпилированный jit компилятором... и пул строк тоже никогда не выгружается...

в пул строк не все строки попадают, а только нужные

Кстати позавчера лор заглючил и вывелось пару системных сообщений.

Оказывается он именно на Томкат))

>и не только, еще sun jvm не выгружает нативный код откомпилированный jit компилятором...

Как минимум вместе с классом должен бы выгружаться, не?

и пул строк тоже никогда не выгружается...

Выгружается: http://stackoverflow.com/questions/2431540/garbage-collection-behaviour-for-s...

>Мне помогали такие настройки:

JAVA_OPTS=" -XX:+CMSClassUnloadingEnabled XX:+CMSPermGenSweepingEnabled"

Пермгены практически исчезли

Еще можно добавить:

-XX:MaxPermSize=256m

Это скорее к spring vs ejb, чем tomcat vs glassfish, т.к. много где используют спринг и под полноценными AS

http://www.linux.org.ru/server.jsp