Comments 34
<?=«Hello, world!»;?>
Простите, вырвалось.
Простите, вырвалось.
А что за контейнер сервлетов используется в Glassfish? Tomcat 7.0 с поддержкой Servlet API 3.0 вроде как ещё не вышел.
Если мне не изменяет память, там таки модификация Tomcat.
>Tomcat 7.0 с поддержкой Servlet API 3.0 вроде как ещё не вышел
а, кстати, когда планируется? побегал по тырнетам, нигде не нашел сроков. может ищу плохо, или в рассылках каких анонсы проскакивали?
а, кстати, когда планируется? побегал по тырнетам, нигде не нашел сроков. может ищу плохо, или в рассылках каких анонсы проскакивали?
Нравится мне новый API.
Надеюсь услышать больше на sun tech days.
Надеюсь услышать больше на sun tech days.
Судя по программе, на sun tech days будет обзор по различным нововведениям, не только Servlet API 3.0… Не удивлюсь если даже презентации будет с одного из официальных вебинаров, которые кстати были в декабре)… Хотя туда тоже собираюсь)
Интересно будет услышать информации о судьбе Glassfish вообще. Ведь теперь Oracle позиционирует его как «Reference design»… Уже скачал WebLogic, смотрю, что да как. Хотя, честно говоря, мне вполне хватает возможностей GlassFish.
Эдак мы скоро на Spring забьем, за ненужностью.
Я так понял, что Servlet API 3.0 даёт возможность полностью отказаться от дескриптора развёртывания (web.xml и faces-config.xml) благодаря аннотациям Java-кода. Это так или несовсем?
Поправьте в статье responce -> response
Что-то мне кажется, что плюшек маловато для «3.0»…
Аннотации — давно пора было сделать, иногда полезно.
Динамическая регистрация сервлетов — зачёт, я даже знаю где это облегчит жизнь.
Асинхронная работа — наверняка полезно, хоть и не сталкивался с такой необходимостью.
Ограничение доступа по ролям — по сравнению с Spring Security (acegi), как трёхколёсный велосипед рядом с космическим кораблём.
Итого, 1.5 из 4 плюшек реально выглядят полезными. «Маловато будет!»
Аннотации — давно пора было сделать, иногда полезно.
Динамическая регистрация сервлетов — зачёт, я даже знаю где это облегчит жизнь.
Асинхронная работа — наверняка полезно, хоть и не сталкивался с такой необходимостью.
Ограничение доступа по ролям — по сравнению с Spring Security (acegi), как трёхколёсный велосипед рядом с космическим кораблём.
Итого, 1.5 из 4 плюшек реально выглядят полезными. «Маловато будет!»
Про асинхронную работу непонятно.
Как в итоге результат работы прилетит к клиенту?
Как в итоге результат работы прилетит к клиенту?
Или это просто для того, чтобы долгая операция не тормозила все на свете и выполнялась в отдельном потоке?
По сути для того, чтобы породить новый поток, который займется обработкой долгой операции со своей копией риквеста, а пользователю отдать сразу респонс. Как поступать по окончании долгой операции — решать Вам. В частности используя AsyncContext.complete() пыполнить нечто, что отразится на UI клиента.
все таки в старом добром web.xml есть плюс — можно посмотреть какой сервлет на какой URL маппится в одном файле… То же самое касается и диспатчер сервлета для спринга. Да, аннотации в Spring 2.5+ — классно, но когда куча контроллеров, очень удобно видеть какой контроллер на какой URL повешан, опять же, в одном файле :)
Либо можно взять за правило давать схожие имена сервлетам (контроллерам в Spring MVC) очень близкие к URL паттернам :)
Либо можно взять за правило давать схожие имена сервлетам (контроллерам в Spring MVC) очень близкие к URL паттернам :)
простите за офтоп, но что это за прозрачные рыбки?
Sign up to leave a comment.
Java EE 6. Что нового в Servlet API 3.0