/server/default/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml (заменяем в трех местах – первые два определяют порты по умолчанию, третье место определяет XSLT-преобразование, которое применяется для конфигурационного файла server.xml.) У меня эти три места были приведены к следующему виду:

<bean>
<property name=”serviceName”>jboss.web:service=WebServer</property>
<property name=”port”>80</property>
<property name=”description”>JBoss Web HTTP connector socket; also drives the values for the HTTPS and AJP sockets</property>

<bean>
<property name=”serviceName”>jboss.web:service=WebServer</property>
<property name=”bindingName”>HttpsConnector</property>
<property name=”port”>443</property>
<property name=”description”>JBoss Web HTTPS connector socket</property>
</bean>

<Connector>
<xsl:for-each select=”@*”>
<xsl:choose>
<xsl:when test=”(name() = ‘port’ and . = ’80′)”>
<xsl:attribute name=”port”><xsl:value-of select=”$port” /></xsl:attribute>
</xsl:when>
<xsl:when test=”(name() = ‘port’ and . = ’8009′)”>
<xsl:when test=”(name() = ‘redirectPort’)”>
<xsl:attribute name=”redirectPort”><xsl:value-of select=”$portHttps” /></xsl:attribute>
</xsl:when>
<xsl:when test=”(name() = ‘port’ and . = ’443′)”>
<xsl:attribute name=”port”><xsl:value-of select=”$portHttps” /></xsl:attribute>
</xsl:when>
<xsl:otherwise>

2. /server/default/deploy/jbossweb.sar/server.xml

Здесь для наших настроек самое главное будет выглядеть так:

<!– A HTTP/1.1 Connector on port 8080 –>
<Connector protocol=”HTTP/1.1″ port=”80″ address=”${jboss.bind.address}”
connectionTimeout=”20000″ redirectPort=”443″ />

<!– A AJP 1.3 Connector on port 8009 –>
<Connector protocol=”AJP/1.3″ port=”8009″ address=”${jboss.bind.address}”
redirectPort=”443″ />

<!– SSL/TLS Connector configuration using the admin devl guide keystore–>
<Connector protocol=”HTTP/1.1″ SSLEnabled=”true”
port=”443″ address=”${jboss.bind.address}”
scheme=”https” secure=”true” clientAuth=”false”
keystoreFile=”${jboss.server.home.dir}/conf/mykeystore”
keystorePass=”qwerty” sslProtocol = “TLS” />

Здесь keystore-путь к файлу, содержащему ключи, необходимые для работы HTTPS. Если у вас такого файла нет, вы можете сгенерировать самоподписанный сертификат с использованием стандартной джавовой тулзы keytool (лежит в директории bin в JDK) следующей командой:

<blockquote>keytool –genkey –alias jboss –keypass qwerty –keyalg RSA –keystore mykeystore –validity 3650</blockquote>

Соответственно, keystorePass- пароль для этой связки ключей.

Интересно, что если сконфигурировать server.xml, но оставить bindings-jboss-beans.xml таким же, то JBoss запустится, но порты будут использованы не те. Не только у меня это вызывает недоумение, но, судя по топику http://community.jboss.org/message/540960?tstart=0, это решение (выполнение дополнительного XSLT преобразования над server.xml) было продиктовано исторически, и в данный момент уже не является чем-то необходимым. Поэтому, скорее всего, в следующих версиях JBoss AS такого дублирования не будет.

Итак, осталось только исправить на всякий случай еще один конфиг, использующий порты 8080 и 8443 – /server/default/deployers/jbossws.deployer/META-INF/jboss-beans.xml :

<!–
Set these properties to explicitly define the ports that will be used for rewriting the SOAP address.
Otherwise the ports will be identified by querying the list of installed connectors.
If multiple connectors are found the port of the first connector is used.–>
<property name=”webServiceSecurePort”>443</property>
<property name=”webServicePort”>80</property>
</bean>

Последний шаг – для каждого WAR указать в дескрипторе web.xml на необходимость использования именно защищенного HTTPS протокола. Для этого в web.xml необходимо добавить строки:

<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Context</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

В первую очередь это можно проверить на встроенных админ-панельках джейбосса (ROOT.war, admin-console.war и тд).

Итак, для настройки 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”, однако, если вы используете сокетный транспорт, вам необходимо будет вместо имени указать порт.

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.

String convertedString = new String (string.getBytes ("iso-8859-1"), "UTF-8");

Вроде работает. Надеюсь в будущем покопать глубже, а пока останется такой миникостыль.

Но мы можем сделать самостоятельно из нашего приложения некий “микрозагрузчик”, который создает AppDomain, конфигурирует его и запускает сам себя, используя сконфигурированный AppDomain. Это действительно работает, причем в самом примитивном случае код очень компактен :

 
 AppDomainSetup setupInfo = new AppDomainSetup();
 string entryAssemblyPath = Assembly.GetEntryAssembly().Location;
 string entryAssemblyDir = Path.GetDirectoryName(entryAssemblyPath);
 setupInfo.ApplicationBase = Path.GetDirectoryName(entryAssemblyPath);
 setupInfo.ConfigurationFile = Path.Combine(entryAssemblyDir, "MyApp.exe.config");
 
 AppDomain forkedDomain = AppDomain.CreateDomain(Guid.NewGuid().ToString(), null, setupInfo);
 forkedDomain.ExecuteAssembly(Assembly.GetEntryAssembly().Location);
 AppDomain.Unload(forkedDomain);

Однако, необходимо следить за тем, чтобы такие ухищрения не приводили к сильной деградации производительности на этапе загрузки. Возможно, стоит написать отдельную сборку, которая будет загружать уже то, что нужно нам. Эта сборка будет очень малого размера, и работать будет практически без потери производительности.

А теперь подумаем, что произойдет, если у приложения, обработанного с помощью NBox (а это, как правило, один-единственный исполняемый файл), изменить имя файла. Если приложение не использовало config-файлы, то все будет ок. Но в противном случае – при запуске – CLR просто не подцепит старый конфиг, и приложение, скорее всего, работать не будет. Но, используя вышеприведенные приемы, мы можем заставить NBox распознать config-файл, и перезапустить самого себя, предварительно сконфигурировав AppDomain нужным config-файлом. А чтобы работа по разворачиванию файлов и сборок не производилась дважды, NBox может извлечь файлы во время начального запуска, и, перезапустившись, уже не извлекать файлы, работая со сборками. Таким образом можно минимизировать потери производительности, одновременно получая еще одну степень свободы в том, как сконфигурировать запускаемое приложение.

В принципе, теперь даже не обязательно извлекать config-файл рядом с exe-файлом упакованного приложения. NBox может закешировать извлекаемые config-файлы во временной директории, извлекая их заново в случае необходимости. Для пользователя это означает минус один файл, создаваемый в каталоге приложения, а для разработчика – уверенность в том, что его конфигурация будет применена независимо от названия exe-файла.

PS. Интересно, что метод AppDomainSetup.SetConfigurationBytes, который бы мог избавить нас от использования файлов в таких случаях, похоже, просто не работает Здесь тред об этом : AppDomainSetup.SetConfigurationBytes has no visible effect on configuration…

Сегодня наконец собрался с мыслями, почистил файлы проекта, и выложил все на гуглокод, благо sourceforge и codeplex уже попробовал. Google code очень понравился своей беспроблемностью в залитии файлов и работе с SVN. Вспоминая, как я трахался с sourceforge через SFTP чтобы залить туда пару архивов, могу сказать, что здесь все очень и очень удобно.

Итак, сайт проекта находится здесь http://code.google.com/p/minifmod4net/

Код использования библиотеки прост как пять копеек, достаточно взглянуть на тестовый пример, чтобы все стало ясно. Только один момент – если вы желаете использовать ее в своей программе, то вам придется сменить режим генерации кода с AnyCPU на x86, поскольку имеется нативная DLL с 32-битным кодом, и в режиме AnyCPU на какой-нибудь 64-битной винде программа не запустится, мотивировав отказ исключением наподобие ImageBadFormatException. Если же х86 специфицировать явно, то все будет работать и на 64-битных Windows.

PS. Поздравляю всех с наступившим 2010 годом, надеюсь, он принесет всем нам немало радости и профессиональных успехов

try {
  // Блок, который может вызвать исключения Exception1, Exception2
  // или исключение любого другого типа
} catch (Exception1 exc) {
  logger.WarnException("An exception has been occured : {0}", exc);
} catch (Exception2 exc) {
  logger.WarnException("An exception has been occured : {0}", exc);
}

Проблема в том, что мы не можем никак избежать дублирования кода. Единственный выход – создать отдельный метод-обработчик, в котором и инкапсулировать логику. Но – во-первых, это может оказаться неудобным, поскольку локальные переменные, которые могут понадобиться в обработчике, придется передавать при вызове функции, а во-вторых, сам по себе вызов функции – это еще несколько тактов процессора.
Хотелось бы иметь способ, который бы позволял писать, скажем, следующим образом :

try {
  // 
} catch (Exception1, Exception2 exc as Exception) {
  // exc имеет тип Exception
}

(Предполагается, что типы Exception1 и Exception2 занаследованы от базового класса Exception).
Этот код мог бы преобразовываться в следующий :

 
Exception exc = null;
try {
  // 
} catch (Exception1 exc1) {
  exc = exc1;
  goto exception_real_handler;
} catch (Exception2 exc2) {
  exc = exc2;
  goto exception_real_handler;
}
 
exception_real_handler:
// Работаем с exc как с базовым типом Exception.

На мой взгляд, это было бы не сложно реализуемым дополнительным синтаксическим сахаром. Вполне применимо к c#, java и C++. Хотя, на счет последнего сомневаюсь, поскольку в С++ на поверку все оказывается несколько сложнее, чем изначально предполагаешь

Единственное – это необходимо продумать, каким образом компилятор должен реагировать на конструкции вида catch (Exception1, Exception2 exc as Exception) в случае, если Exception1 занаследован от Exception2. Мне видятся несколько путей, по которым мог бы пойти компилятор.

• Выдавать ошибку при компиляции.
  Самый жесткий поход. На мой взгляд, это излишне.
• Игнорировать наличие более конкретных типов.
  Т.е. если идет строчка catch (Exception1, Exception2 exc as Exception), в которой Exception1 : Exception2, то она будет интерпретирована как простой catch (Exception2). Вполне понятный подход.
• Игнорировать и выдавать предупреждение – наверное, самый правильный способ.

const HandlePointer<lib3dsfile>& file = loadFile();

Функция loadFile() возвращала HandlePointer<Lib3dsFile> по значению, и по идее это значение должно было быть привязано (bind) к константной ссылке. Время жизни временного (temporary) объекта в этом случае по Стандарту должно быть продлено и временный объект должен быть жив до тех пор, пока жива константная ссылка. Однако, добавив диагностических логов, я с удивлением отметил, что деструктор временного объекта в данном случае вызывается сразу после выполнения этой строки, не дожидаясь выхода ссылки из области видимости. Замена ссылки на объект-копию магическим образом исцеляло программу, временный объект уничтожался после вызова конструктора копий, и программа работала как раньше.

Добавив еще чуть больше логов, я удивился еще раз, увидев, что в указанном выражении вызывается
оператор преобразования HandlePointer<T>::operator T& () , то есть объект преобразовывался к самому себе, однако при этом объект уже не привязывался к константной ссылке, а уничтожался автоматически после вычисления полного выражения (full expression).

Дома для проверки написал тестовую программу, которая объявляла класс Test и оператор преобразования к типам Test& и const Test& :

class Test
{
public:
	Test() { printf("Default constructor\r\n"); }
	~Test()	{ printf("Destructor\r\n");	}
	Test(const Test& copy) { printf("Copy constructor\r\n"); }
	Test& operator= (const Test& copy) {
		printf("operator =\r\n");
		return *this;
	}
	//
	operator Test& () {
		printf("operator Test&\r\n");
		return *this;
	}
	operator const Test& () const {
		printf("operator const Test&\r\n");
		return *this;
	}
}
 
Test someFunc()
{
	return Test();
}
 
int main()
{
	{
		printf("Begin\r\n");
		const Test& test = someFunc();
		printf("End\r\n");
	}
}

Натравив на него компиляторы Visual C++ и GCC, посмотрел на результаты. Произошло все так же, как и в случае шаблонных классов :

Вывод программы, скомпилированной Visual C++ :
Begin
Default constructor
End
Destructor

Вывод программы, скомпилированной GCC :
Begin
Default constructor
operator Test&
Copy constructor
Destructor
operator Test&
Destructor
End

На обилие конструкторов копий и деструкторов в выводе GCC можно не обращать внимания – это
всего лишь говорит о том, что GCC не выполнил здесь RVO (Return Values Optimization). Главное -
что в Visual C++ временный объект живет до конца блока { }, а в GCC уничтожается сразу.

Почему поведение GCC здесь мне представляется неверным ? Допустим, у вас есть класс. У класса есть
дефолтные операторы преобразования их к ссылке и к константной ссылке, генерируемые компилятором автоматически. И временные объекты успешно привязываются к константным ссылкам, продлевая их время жизни. Однако, если вы вдруг (как сейчас я) захотите написать свою версию такого оператора (что в принципе, бессмысленно, но в контексте использования шаблонов смысл приобретает), то вы уже не сможете действовать по старым правилам. Таким образом, явное определение пользовательского оператора преобразования (такого же, как и дефолтный, по сути) изменяет поведение объектов и семантику в целом.

В общем, сбило порядочно меня все это с толку, и я обратился за помощью на блог Алены С++ (в котором как раз недавно читал про RVO и привязку временных объектов к const& ) и на RSDN.
На следующий день поступили комментарии, позволяющие разобраться в том, что же все-таки происходит и какой из компиляторов в данном случае прав.

Краткое резюме беседы (для тех, кому лениво читать обсуждение) :

Здесь мы видим следствие изначального внутреннего противоречия в Стандарте 98 (см ветку на RSDN).
Стандарт был скорректирован в дальнейшем в ходе внесения правок и уточнений.
На данный момент корректным поведением является поведение, при котором компилятор не должен вызвать переопределенные операторы преобразования в случае, если это преобразование выполняется к ссылке на тот же тип или к объекту того же типа:

12.3.2/1
…
A conversion function is never used to convert a (possibly cv-qualified)
object to the (possibly cv-qualified) same object type (or a reference to it)

Таким образом, компилятор GCC на данный момент не соответствует исправленному Стандарту.
Что ж, печально, придется использовать вместо неявных преобразований явный вызов функции.
Хотя, возможно, есть способ, который бы позволил ограничить шаблонный метод преобразования таким образом, чтобы он не использовался, когда тип T идентичен типу U ? Я попробовал пошаманить с
шаблонами и SFINAE, но пока ничего путного не вышло. Если у кого-нибудь есть такое решение,
было бы интересно о нем узнать.