На днях подумал о том, что было бы неплохо написать несколько постов на тему настройки, использования и разработки на базе платформы JBoss, тем более что уже имеется некий опыт этих манипуляций. Пока, пожалуй, будем говорить о JBoss Application Server 5.1, возможно, чуть позже затронем тему JBoss AS 6 и JBoss Portal, но пока ограничимся Application Server’ом версии 5.1 GA. Это стабильная версия, ее можно скачать на официальном сайте jboss.org.
Итак, для настройки JBoss AS для разработки и использования в продакшене обычно требуется:
1. Настройка режима отладки JPDA
1. Настройка портов, на которые будут биндиться сервисы и HTTP-коннекторы.
2. Настройка админок так, чтобы анонимусы не могли ими воспользоваться
3. Настройка различных сервисов (например, сервис отправки email)
4. Тюнинг текущей конфигурации (отключение ненужных сервисов, изменение настроек)
По порядку эти вещи делать не обязательно, поскольку JBoss AS распространяется в зипованном бандле, который запускается “здесь и сейчас”, поэтому я буду описывать эти несложные, в общем-то, вещи, отдельно, в виде небольших шпаргалок.
Итак, начнем с настройки режима отладки JBoss.
Первым делом разработчик, который начал использовать JBoss, хочет заглянуть в свое приложение отладчиком. Для того, чтобы JBoss поддерживал возможность отладки, необходимо поправить файл run.bat, добавив туда опции для виртуальной машины. (В линуксе этим файлом будет, соответственно, run.sh) Я обычно копирую run.bat в run_jpda.bat и добавляю требуемые параметры после, например, этих строк:
if “x%JAVA_OPTS%” == “x” (
set “JAVA_OPTS=-Dprogram.name=%PROGNAME%”
) else (
set “JAVA_OPTS=-Dprogram.name=%PROGNAME% %JAVA_OPTS%”
)
Дописываем после них
set “JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_shmem,address=jboss,server=y,suspend=n”
транспорт может быть также dt_socket, флаг suspend означает то, будет ли перед запуском программа ждать подключения отладчика или запустится сразу. По указанному адресу (address) клиент JPDA будет подключаться к JBoss’у и в своей любимой IDE вы пропишете именно его. В данном случае адресом выступает строка “jboss”, однако, если вы используете сокетный транспорт, вам необходимо будет вместо имени указать порт.
Обнаружил сегодня очередной косяк в Hibernate, когда делал NativeQuery для таблицы, в
которой имеется поле типа TEXT. Как известно, хибер по умолчанию не создает такие поля,
а создает VARCHAR(255) для строковых значений, и
тип TEXT я задал специально при создании Entity-бинов с использованием аннотации
@Column(columnDefinition = “text”). И вот теперь select через NativeQuery не работает,
потому что
MySQL5: No Dialect mapping for JDBC type: -1
Из обсуждений http://opensource.atlassian.com/projects/hibernate/browse/HHH-1483
выяснилось, что этот диалект почему-то не хочет поддерживать тип TEXT.
В результате выяснилось, что победить эту проблему можно тремя способами :
1. Отказаться от использования TEXT в пользу VARCHAR(65535) – но это не всегда возможно,
особенно если база уже работает, и при выполнении alter table часть данных будет обрезана.
2. Заюзать хибернейтовский метод addScalar при формировании запроса.
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querysql.html (16.1.1 Scalar queries)
К сожалению, этот метод также не является идеальным, поскольку при использовании
EJB3 (а я использую именно его) не представляется возможным лезть на уровень ниже и
кастить интерфейс Query к хибернейтовскому SQLQuery, тем самым завязываясь на текущей
хибернейтовской имплементации EJB3.
3. Пропатчить класс-диалект, подменив его своим или занаследовавшись от него и добавив
специальный кейс для типа TEXT. В данном случае все прошло великолепно, я закинул
класс
public class MySQL5InnoDBDialectPatched extends org.hibernate.dialect.MySQL5InnoDBDialect { public MySQL5InnoDBDialectPatched() { super(); // register additional hibernate types for default use in scalar sqlquery type auto detection registerHibernateType(Types.LONGVARCHAR, org.hibernate.Hibernate.TEXT.getName()); } } |
в свойства persistence.xml, и все заработало.
Единственное, что пришлось добавить в проект – compile-time-зависимости для сборки
ejb-джарника. В моем случае это был всего лишь 1 файл hibernate3.jar.
При использовании commons.fileupload возникла проблема : русский текст, вводимый в input’ы, приходил в непонятной кодировке. Пробовал повесить фильтр, в котором выставить request’у и response’у кодировку utf-8 принудительно, но не помогло. Пробовал установить accept-charset на форме, тоже не помогло.
Единственное найденное решение – у получаемых значений конвертить кодировку из iso-8859-1 в utf-8 :
String convertedString = new String (string.getBytes ("iso-8859-1"), "UTF-8"); |
Вроде работает. Надеюсь в будущем покопать глубже, а пока останется такой миникостыль.
0