16-го июня будет 100 лет со дня основания IBM, хотя тогда компания называлась Computing Tabulating Recording Corporation.
Краткий исторический экскурс:
IBM Centennial Film: They Were There - People who changed the way the world works
IBM Centennial Film: 100 X 100 - A century of achievements that have changed the world
Thursday, January 27, 2011
Включение поддержки HTTPS для Tomcat (v6.0)
В принципе ничего сложно в этом, нет, но как всегда пришлось немного повозиться.
[шаг 1] Первым делом я предлагаю перевести логгинг в режим отладки. Для этого в файле logging.properties (находится в ${CATALINA_HOME}/conf или если его там нет, то нужно создать этот файл и поместить в classpath, или добавить, например, в WEB-INF/) нужно установить консольный логгинг в отладку:
[шаг 2] Далее нужно сгенерировать ключи, это делается с помощью keytool, которая обычно входит в JDK:
По умолчанию файл ключей кладется в ${user.home} . Для того, чтобы сгенерировать ключи в заданный файл: \a\path\a\keystore, то это можно сделать так:
Keytool запросит пароль (пишут, что по умолчанию Tomcat использует changeit, но мне пришлось задавать его явно в описателе коннектора), запросит ФИО издателя ключей, отдел, компанию и т.д.
[шаг 3] Правим server.xml, который обычно находится в ${CATALINA_HOME}/conf. Нужно раскомментировать описание для SSL HTTP/1.1 Connector и добавить туда соотв. атрибуты:
Расположение файла с ключами и пароль пришлось задавать явно. Алгоритм можно не задавать. Замечу, что для Oracle/Sun JVM алгоритм будет SunX509. Для IBM JVM значение скорее всего будет IbmX509. Как следствие, сгенерированные ключи могут быть не совместимы. Так ключи, сгенерированные с помощью Oracle/Sun JVM, у меня не сработали для IBM JVM.
Если все ок, то https://localhost:8443 должно привести к открытию страницы приветствия Tomcat. Если уже есть какие-то приложения, то ничего менять не надо. Они должны также запускаться под https по 8443 порту.
Примечание: если менять серверные настройки в eclipse, нужно убедиться, что файл настроек в рабочей области действительно синхронизирован с файлом на диске. Иначе все изменения в рабочей области никак не скажутся на работе сервера.
Подробнее можно посмотреть здесь и здесь.
[шаг 1] Первым делом я предлагаю перевести логгинг в режим отладки. Для этого в файле logging.properties (находится в ${CATALINA_HOME}/conf или если его там нет, то нужно создать этот файл и поместить в classpath, или добавить, например, в WEB-INF/) нужно установить консольный логгинг в отладку:
java.util.logging.ConsoleHandler.level = DEBUG
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
[шаг 2] Далее нужно сгенерировать ключи, это делается с помощью keytool, которая обычно входит в JDK:
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
По умолчанию файл ключей кладется в ${user.home} . Для того, чтобы сгенерировать ключи в заданный файл: \a\path\a\keystore, то это можно сделать так:
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \
-keystore \a\path\a\keystore
Keytool запросит пароль (пишут, что по умолчанию Tomcat использует changeit, но мне пришлось задавать его явно в описателе коннектора), запросит ФИО издателя ключей, отдел, компанию и т.д.
[шаг 3] Правим server.xml, который обычно находится в ${CATALINA_HOME}/conf. Нужно раскомментировать описание для SSL HTTP/1.1 Connector и добавить туда соотв. атрибуты:
<connector
port="8443"
maxthreads="150"
algorithm="SunX509"
scheme="https"
secure="true"
sslenabled="true"
keystorepass="changeit" clientauth="false"
keystorefile="${user.home}/.keystore"
sslprotocol="TLS">
</connector>
Расположение файла с ключами и пароль пришлось задавать явно. Алгоритм можно не задавать. Замечу, что для Oracle/Sun JVM алгоритм будет SunX509. Для IBM JVM значение скорее всего будет IbmX509. Как следствие, сгенерированные ключи могут быть не совместимы. Так ключи, сгенерированные с помощью Oracle/Sun JVM, у меня не сработали для IBM JVM.
Если все ок, то https://localhost:8443 должно привести к открытию страницы приветствия Tomcat. Если уже есть какие-то приложения, то ничего менять не надо. Они должны также запускаться под https по 8443 порту.
Примечание: если менять серверные настройки в eclipse, нужно убедиться, что файл настроек в рабочей области действительно синхронизирован с файлом на диске. Иначе все изменения в рабочей области никак не скажутся на работе сервера.
Подробнее можно посмотреть здесь и здесь.
Tuesday, January 18, 2011
Выбор ORM.
Так получилось, что рано или поздно нужно использовать persistence, что привело к необходимости искать подходящую ORM-технологию. PM предложил использовать openJPA. Но, думаю, будет полезно разместить здесь небольшой обзор существующих ORM-решений. Скорее всего буду возвращаться к этому посту и периодически обновлять его.
1. Чистый SQL. Есть люди, которые утверждают, что никакой ORM не нужен, что чистый SQL работает намного быстрее. На мой взгляд, утверждение весьма спорное в силу того, что:
a) не у всех есть достаточный опыт в SQL для разработки устойчивых, масштабируемых систем.
b) ряд ORM технологий допускают native - запросы к базам.
c) ряд ORM технологий инкапсулируют многочисленные native настройки, а также возможность эти самые native настройки менять напрямую.
d) в ряде случаев, опять-таки если не знать некоторые тонкие настройки производительность будет даже хуже, чем при использовании ORM-решения.
2. Hibernate: пишут, что это де-факто стандарт. Хорошая документация. Есть порт для .NET. Пока не проверял, но пишут, что Hibernate одно из наилучших в плане производительности решений. Опыт работы с Hibernate часто является ключевым требованием при приеме на работу. Распостраняется согласно LGPL.
3. Apache openJPA. Открытая реализация JPA стандарта от Apache. На удивление хорошая и своевременная документация. Есть много примеров.
4. Apache iBatis. Вообще не имеет ничего общего со стандартом JPA. Хороший выбор для фанатов SQL.
5. Apache Cayenne. Еще одно JPA-решение. Пока не выяснил, в чем принципиальное отличие от openJPA.
Линки по теме:
1. Сравнение Hibernate, OpenJPA и EclipseLink.
2. Stackoverflow тред по теме.
1. Чистый SQL. Есть люди, которые утверждают, что никакой ORM не нужен, что чистый SQL работает намного быстрее. На мой взгляд, утверждение весьма спорное в силу того, что:
a) не у всех есть достаточный опыт в SQL для разработки устойчивых, масштабируемых систем.
b) ряд ORM технологий допускают native - запросы к базам.
c) ряд ORM технологий инкапсулируют многочисленные native настройки, а также возможность эти самые native настройки менять напрямую.
d) в ряде случаев, опять-таки если не знать некоторые тонкие настройки производительность будет даже хуже, чем при использовании ORM-решения.
2. Hibernate: пишут, что это де-факто стандарт. Хорошая документация. Есть порт для .NET. Пока не проверял, но пишут, что Hibernate одно из наилучших в плане производительности решений. Опыт работы с Hibernate часто является ключевым требованием при приеме на работу. Распостраняется согласно LGPL.
3. Apache openJPA. Открытая реализация JPA стандарта от Apache. На удивление хорошая и своевременная документация. Есть много примеров.
4. Apache iBatis. Вообще не имеет ничего общего со стандартом JPA. Хороший выбор для фанатов SQL.
5. Apache Cayenne. Еще одно JPA-решение. Пока не выяснил, в чем принципиальное отличие от openJPA.
Линки по теме:
1. Сравнение Hibernate, OpenJPA и EclipseLink.
2. Stackoverflow тред по теме.
Subscribe to:
Posts (Atom)