Описание задачи:

Вы делаете проект на java под Tomcat. И решили организовать разделы своего сайта в виде поддоменов.
К примеру, на сайте www.domen.xx сделать разделы: mail.domen.xx, user.domen.xx и т.п. В какой-то момент разработки вы с удивлением обанружите, что пользовательская сессия вопреки ожиданиям существует строго в рамках одного домена. То есть юзер авторизовавшись на главной странице (www.domen.xx), переходя почту (mail.domen.xx), теряет авторизацию.

Дело в том, что сессия привязывается к клиенту через cookie с именем JSESSIONID и с пустым доменом. А когда домен не указан, браузер использует полный текущий домен. То есть сессия привязывается не к «domen.xx», а к «www.domen.xx». По неизвестной мне причине в Томкэте нет настроек позволяющих управлять этим поведением.

Несмотря на то, что я пишу на Java уже 2 месяца (о да, это срок :) ), я ни разу не запускал remote debugger. При разработке на GWT этого делать и не нужно — оно как-то само всё это делает. :) Но вот настала весна, моё GWT приложения распустилось, и хочет, чтобы я его выложил на сервер. Но вдруг выяснилось, что просто так оно работать не захотело. А почему, я понять не могу. И значит мне нужен дебагер.

Принцип работы наверное любого удалённого отладчика (remote debugger) прост — контейнер (это может быть и какой-либо сервлет-контейнер, и php-интерпритатор. Полагаю, что интерпритаторы Ruby, Perl, Python работают аналогичным образом), который выполняет приложение настраивается таким образом, что при запуске приложения он либо начинал слушать определенный порт, либо сам пытался коннектиться куда-либо.

Представляю Вашему вниманию обзор высокоуровневой системной архитектуры социальной сети www.campus.ru, разработки компании ООО «Креатив Медиа». На мой взгляд, данный материал интересен тем, что позволяет оценить применимость рассмотренных подходов и технологий в разработке интернет-ресурсов. По крайней мере, когда наша компания начинала проект «Кампус», мне очень не хватало подобной информации.

В бытность мою j2ee программистом, приходилось разрабатывать сайты с достаточно большим количеством страниц, использующие для визуализации ajax и прочие красивости. Контроллеры можно было протестировать при помощи JUnit и моковых запросов\ответов. Но для огромного количества ftl шаблонов и их JavaScript кода такой вариант не подходил.

Уже давно я слышал об инструменте для автоматизации сборки проекта — Ant, но как-то не мог найти ему реального применения в проектах на PHP. Компилить вроде ничего не надо, внешние библиотеки вполне можно подключить через svn:externals, оставались только тесты, которые свободно выполнялись через $ phpunit AllTests.php, да перенос изменений на рабочий сервер (svn export + небольшой самописный скрипт). Даже достаточно хорошая статья об использовании ant в eclipse не подвигла меня на использование сего инструмента, да еще и build файлы писать не хотелось…

Вобщем все как всегда. Какая-то подобная штука вроде бы и не помешала бы, но все и так хорошо работало и лень было изучать псевдопомогающую технологию. Так было до тех пор, пока я не познакомился с Java…

Записал видеоурок, думаю многим начинающим он пойдёт на пользу и ответит на многие вопросы.



Скачать в разрешении 1280x800 можно здесь Размер 32 мегабайта.

Вы узнаете, как создать приложение на GWT в среде Intellij IDEA 9. Мы напишем простой асинхронный запрос, сгенерируем число на сервере, отправим ответ клиенту и выведем результат на экране.

Далее, всё задеплоим на сервер Apache Tomcat и покажем работающий пример.

Конечно, многие нюансы опущены. Всё-таки урок для начинающий гвт-шников!
Удачи в программировании!

ПС. Один момент сглючил при сжатии видео, когда нужно было скопировать библиотеку gwt-servlet.jar с папки GWT 2.0 в папку WEB-INF/lib.

Данная статья описывает по шагам как настроить Tomcat (на текущий момент версия 6.0.26) на работу с разными компонентами Java EE 6.

• Unified EL 2.2 — язык выражений для JSF
• JSF 2.0 реализация — Mojarra (документация)
• JSR 299 реализация — Weld (документация)
• JSR 303 Bean Validation реализация — Hibernate Validator (документация)
• JPA 2.0 реализация — EclipseLink

Вы можете пропустить чтение этой статьи и сразу получить настроенный Tomcat и пример приложения.

 

Если вкраце то jira — это система управления проектами, но установить её дело далеко незаурядное. Читать долгие англоязычные мануалы весьма утомительно, русских статей в интернетах мало сейчас будем исправлять.

В этом топике расскажу о маленьком, но эффективном способе передачи файлов пользователю из сервлета по HTTP протоколу. Используется:

• Apache Tomcat
• Apache Portable Runtime Library
• Apache Tomcat Native Library
• Ваш сервлет, которому нужно отдавать файлы пользователю

Давным-давно я работал в одной большой компании, мы писали JEE приложения. Тогда еще была IntelliJ IDEA 4.0. Один из проектов состоял примерно из 30 модулей. Создание воркспейса с нуля занимало кучу времени, поэтому воркспейс хранился в svn. Кто-то сидел на IDEA 4.0, кто-то на IDEA 5.0, и когда кто-то комитил свои iml'ки и ipr'ки в svn, то другие жутко сердились из-за того, что слетали их личные настройки, поэтому у всех был свой личный воркспейс, а новые программисты мучались с уже нерабочим из svn.

Потом появился мавен и maven-idea-plugin, стало возможно создавать воркспейс из мавен проекта. Потом появился плагин «Maven Integration»: интеграция мавена и IDEA, стало возможно открывать сразу мавен проект.

В начале 2010 года у меня была пара проектов примерно с 20 модулями каждый, и я тратил немного времени на их настройку. Сейчас у меня 20 проектов, в каждом около 50 модулей, у каждого проекта есть несколько бранчей и тэгов. Было очень трудно создавать и переключаться между воркспейсами. Другим программистам тоже было трудно, они тоже тратили много времени на создание и настройку воркспейса. Было ощущение, что программисты совсем не тем занимались.

Хочу поделится результатами внутренних тестов вертикального автоматического масштабирования памяти в Jelastic — облачный хостинг для Java приложений.
В данном примере симитировано поведение web приложения, которое работает на базе Tomcat сервера. Измерения проводились при различных нагрузках. Нагрузка изменялась путем увеличения количества подключенных клиентов. Измерения показаний проводились через админку владельца приложения.

Зачем нужен deploy-скрипт

Grails-приложения очень легко собираются в WAR. Делается это так:

grails war

Помимо того, что WAR собирается, очень хочется этот WAR еще и установить на сервер. В нашем случае это Tomcat. Установка вручную требует некоторой возни:

1. Остановить сервер. Убить процесс, если он не остановился сам.
2. Удалить старые файлы приложения (на всякий случай)
3. Скопировать новый WAR на сервер. Иногда его нужно переименовывать (скажем, в ROOT.war)

В Maven эту работу может проделать, например, cargo plugin. Но с ним много приключений и настройки, причем он не особо учитывает особенности сервере.

Мы также можем использовать shell-скрипт. Но зачем писать на неудобном языке shell, когда есть замечательный кроссплатформенный язык Groovy?

Jelastic — облачный хостинг для ранее разработанных или новых Java приложений.

Отличительные особенности

• 100% поддержка стандартного стека технологий — нет привязки к проприетарному API платформы
• визуальный конструктор топологий — визуализация при создании топологий окружений
• вертикальное масштабирования — наличие которого является критически важным для определенного вида приложений
• широкий набор баз данных и серверов приложений — в ближайшем будущем этот набор будет расширен еще больше

Мы продолжаем развитие Jelastic и рады сообщить о увеличении посадочных мест на борту.

При обновлении приложения до более новой версии необходимо максимально быстро с минимальными задержками и потерями запросов произвести переключение потока пользователей на новую версию. Для решения этой проблемы в разных проектах используются разные подходы. Одним из таких подходов является смена привязки главного домена к окружению с более новой версией приложения.
Как происходит процесс обновления в таком случае? Очень просо — вы настраиваете полноценную работу новой версии приложения в отдельном окружении, а потом производите смену привязки домена к другому IP, или проще говоря переключаете поток пользователей на обновленное окружение. Конечно в этом случае будут возникать
проблемы с кешем DNS серверов. Давайте проанализируем что предлагает Jelastic (Java Elastic Cloud Platform) для решения задачи обновления приложений и как обойти проблему DNS кеша.

Мотивом написания данной статьи послужило прочтение поста «Быстрая разработка веб-приложений на Java» и небольшой когнитивный диссонанс, возникший после прочтения и вопрос, который продолжает попрежднему мучать меня — Зачем такие сложности? Если есть WTP!

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

Для этого мы будем использовать 4 сервера на Linux CentOS 5.5, а так же Apache, Tomcat6, mod_jk, Heartbeat.
web1, web2 сервера — для распределения запросов средствами Apache и отказоустойчивости средствами Heartbeat. tomcat1, tomcat2 сервера — Tomcat сервера для Java-приложения.

Это наш новый промо-ролик для хостинговых компаний. Он раскрывает не все наши преимущества и функциональность, но довольно понятно и вкратце объясняет что мы делаем и зачем. На текущий момент у нас есть два крупных партнера — это хостинговые компании в Европе и в США. Скоро будут объявлены официальные пресс релизы по этому поводу. Есть ряд заинтересованных хостеров в Японии, Австралии и других странах. Jelastic старается сделать облачный хостинг более распространенным решением, дабы дать разработчикам максимальную свободу и независимость при выборе поставщика облачных услуг.

Как и обещали ранее, предоставляем статистику по серверам веб-приложений для Java. Статистические данные отображают текущий срез использования серверов в облачной Java Hosting платформе Jelastic. В статистической выборке участвовало более 2000 окружений. Справедливости ради, стоит отметить что сервера GlassFish и Jetty были добавлены позже. Это обстоятельство влияет на конечную статистику. Тем не менее, мы должны показать текущее состояние, для того чтобы провести анализ изменений в следующем месяце.



Распределение серверов по регионам

Мы продолжаем делиться с вами статистикой использования программного стека на платформе Jelastic. Какими же были предпочтения девелоперов в прошлом месяце?

Статистика использования баз данных MySQL, MariaDB, PostgreSQL и MongoDB

Начнем с SQL баз. Как и прежде MySQL остается неоспоримым лидером. PosgreSQL занимает второе почетное место, за ней следует MariaDB. Единственная среди наших NoSQL баз, MongoDB показала очень хороший результат в ноябре.



Если сравнить текущие данные с октябрьскими, то можно сделать вывод, что количество фанов каждой из баз практически не изменилось.
Ситуация в регионах (Европа и Северная Америка).



Текущие цифры