Java-Bulldozer

Динамическая модификация контекста в Spring

noreply@blogger.com (Никита Кокшаров) — Wed, 28 Oct 2009 12:24:00 +0000

Существует механизм изменения контекста Spring, который запускается после сбора всей информации о нем (из xml и аннотаций) и срабатывает до создания самих bean-ов. Я говорю об интерфейсе org.springframework.beans.factory.config.BeanFactoryPostProcessor, реализуя который вы получаете именно такую возможность. Используя данный механизм очень удобно менять параметры уже объявленных где-то в контексте bean-ов. Объект реализующий этот интерфейс можно зарегистрировать как обычный bean в контексте, либо добавить его на этапе создания контекста, например так:

package com.blogspot.nkoksharov;

import org.springframework.beans.*;
import org.springframework.beans.factory.config.*;

public class SpringTest {

    public void testPostProcessor() {
        ConfigurableApplicationContext context = 
             new ClassPathXmlApplicationContext(new String[] {"/spring/context.xml"}, false);
        context.addBeanFactoryPostProcessor(new BeanFactoryPostProcessor() {
            @Override
            public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
                BeanDefinition definition = beanFactory.getBeanDefinition("sampleBean");
                MutablePropertyValues values = definition.getPropertyValues();
                MockObject object = new MockObject();
                values.addPropertyValue("someProperty", object);
            }
        });
        context.refresh();
        
        ... 

    }

}

Только не забудьте указать в конструкторе контекста аргументу refresh значение false, иначе наш механизм будет вызываться лишь для новых bean-ов добавляемых уж после создания контекста (как это делать я писал тут). При вызове метода refresh произойдет инициализация контекста и наш обработчик будет вызван.

Описанный выше прием оказывается очень полезен в использовании при тестировании, когда нужно изменить какие-то из параметров bean-ов или просто выставить свои значения.

Управление версиями в Maven

noreply@blogger.com (Никита Кокшаров) — Mon, 17 Aug 2009 13:17:00 +0000

После очередного релиза проекта приходится менять его версию, проходясь при этом по всем pom-файлам. Процедура эта довольно утомительная и избавить от нее поможет versions-maven-plugin.

Достаточно выставить в головном pom-файле новую версию проекта и затем выполнить команду:

mvn versions:update-child-modules

Как вы наверное догадались, команда выполнит обновление всех версий проекта в pom-файлах дочерних модулей. Если же, по какой-то причине, вы остались недовольны проделанной работой плагина, то содержимое pom-файлов можно легко вернуть в исходное состояние командой:

mvn versions:revert

Чтобы удалить backup-ы pom-файлов выполните:

mvn versions:commit

Помимо выполнения обновления версии проекта, есть еще несколько полезных возможностей. Вывод списка новых версий зависимостей проекта, доступных из репозитария:

mvn versions:display-dependency-updates

Список новых версий плагинов используемых в проекте:

mvn versions:display-plugin-updates

Параметры производительности nginx и tapestry 5

noreply@blogger.com (Никита Кокшаров) — Sat, 08 Aug 2009 12:43:00 +0000

Думаю, что вам известно о HTTP-сервере nginx, а также возможности его использования в качестве front-end сервера для передачи разных ресурсов клиенту. Использование nginx позволяет разгрузить ваш сервер Java-приложений от лишней работы со стататическими ресурсами.

Отмечу лишь несколько основных, на мой взгляд параметров, влияющих на производительность системы использующей Nginx и веб-фреймворка Tapestry 5.

Параметры для nginx, выставляемые в nginx.conf:

worker_processes - кол-во процессов, обеспечивающих загрузку ресурсов с диска. Значение зависит от объема ресурсов и скорости носителя с которого производится чтение. Также играет роль число ядер/процессоров в вашем сервере, думаю, что значение должно быть не меньше чем их кол-во;
worker_connections - максимальное кол-во одновременных соединений с сервером. Следует выбрать оптимальное число, которое сможет держать сам сервер-приложений. Именно верный порог соединений предотвратит DDOS-атаки на ваш сервер и даст уверенность в том, что ваш сервер будет устойчиво работать.

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

tapestry.page-pool.hard-limit - максимальное значение страниц в пуле. Следует учесть, количество локалей поддерживаемых вашим приложением, т.к. для каждой локали создается отдельный экземпляр страницы (по-умолчанию значение 20);
tapestry.page-pool.soft-limit - кол-во страниц в пуле, после которого tapestry перейдет в ожидание освободившихся страниц. Пока число страниц в пуле не достигнет этого значения и свободных экземпляров не будет, они будут создаваться (по-умолчанию значение 5).

Использование LiquiBase с Hibernate и Maven. Часть 2

noreply@blogger.com (Никита Кокшаров) — Mon, 03 Aug 2009 15:30:00 +0000

Теперь о том, что касается изменений которые вносит hibernate в структуру БД, при добавлении/изменении сущностей, если в настройках указан параметр hibernate.hbm2ddl.auto=update. Как продолжить пользоваться этой возможностью, если теперь для всех изменений структуры БД мы должны использовать только liquibase? Было бы не плохо получать sql генерируемый hibernate, который можно легко поместить в changeset liquibase. Для этого необходимо подключить hibernate3-maven-plugin к модулю, в котором используется hibernate:

<properties>
      <hibernate.update>false</hibernate.update>
      <hibernate.create>false</hibernate.create>
</properties>
<build>
      <plugins>
          ...
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>hibernate3-maven-plugin</artifactId>
            <version>2.2</version>
            <configuration>
              <componentProperties>
                <outputfilename>schema.sql</outputfilename>
                <configurationfile>/resources/hibernate.cfg.xml</configurationfile>
                <export>false</export>
                <update>${hibernate.update}</update>
                <create>${hibernate.create}</create>
                <drop>true</drop>
              </componentProperties>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>postgresql</groupId>
                    <artifactId>postgresql</artifactId>
                    <version>8.3-603.jdbc4</version>
                </dependency>
            </dependencies>
          </plugin>
      </plugins>
</build>

Необоходимым условием для работы плагина является наличие файла hibernate.hbm.xml, в нем должны содержаться следующие настройки:

<hibernate-configuration>
    <session-factory>
        <property name="hibernate.connection.driver_class">...</property>
        <property name="hibernate.connection.url">...</property>
        <property name="hibernate.connection.username">...</property>
        <property name="hibernate.connection.password">...</property>
        <property name="hibernate.dialect">...</property>

        <mapping class="ru.somesite.SomeObject"/>
        ...
    </session-factory>
</hibernate-configuration>

Не забудьте также и о том, что теперь все маппинги классов тоже нужно указывать в этом файле, а не в каком-нибудь SessionFactoryBean, если используете Spring. Настройка SessionFactoryBean будет выглядеть примерно так:

<bean id="sessionFactory"
        class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="configLocation" value="classpath:/hibernate.cfg.xml" />
        <property name="hibernateProperties">
            <props>
                ...
                <prop key="hibernate.hbm2ddl.auto">validate</prop>
            </props>
        </property>
</bean>

Стоит отметить, что параметру hibernate.hbm2ddl.auto, в вашем проекте, нужно присвоить значение validate. Теперь при каждом выполнении команды:

mvn hibernate3:hbm2ddl -Dhibernate.create=true

вам будет выводится sql генерируемый hibernate, который можно вставить в changeset. Параметр -Dhibernate.create=true следует указывать, в том случае, когда вам требуется SQL всей схемы БД. В случае, когда требуется получить SQL-команды, выполняемые hibernate для обновления схемы БД, то вместо первого параметра используйте -Dhibernate.update=true.

И помните, что в случае обновления БД вам нужно будет следить SQL, генерируемым hibernate, т.к. не все изменения параметров объектов входят в SQL (к примеру, hibernate не будет создавать некоторые constraint-ы).

Использование LiquiBase с Hibernate и Maven. Часть 1

noreply@blogger.com (Никита Кокшаров) — Thu, 09 Jul 2009 18:00:00 +0000

Когда-то я представлял вашему вниманию инструмент для управления изменениями в БД - liquibase. Теперь я решил описать как его можно использовать в проектах с maven-сборкой, и hibernate.

Для начала необходимо создать отдельный maven-артефакт, который будет содержать только ресурсы - xml-файлы с changeSet-ами от liquibase. Структура файлов в папке resources нашего артефакта следующая:

    /changelogs/версия_проекта/*-changelog.xml
    /changelogs/версия_проекта/release-changelog.xml
    /project-changelogs.xml

Файл project-changesets.xml включает в себя набор файлов release-changelog.xml всех версий проекта, вот пример его содержимого:

<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.9"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog/1.9 
                http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">

     <include file="changelogs/1.0/release-changelog.xml" relativeToChangelogFile="true"/>
     <include file="changelogs/1.1/release-changelog.xml" relativeToChangelogFile="true"/>
     <include file="changelogs/2.0/release-changelog.xml" relativeToChangelogFile="true"/>
     ...
</databaseChangeLog>

Таким же образом файлы release-changelog.xml включают в себя список файлов с измененями, находящихся в той же папке и касающихся лишь данной версии проекта. Сами изменения я предпочитаю описывать не пользуясь при это тэгами liquibase, а использую привычный SQL.

Благодаря наличию в liquibase такого понятия как "контекст", можно разделить все операции над БД на три контекста:

schemedata - контекст в котором будут отражены изменения структруры базы;
initdata - контекст определяющий данные для инициализации БД, например добавление новых пользовательских ролей;
migratedata - контекст используемый при изменении "живых" данных, т.е данных появляющихся в системе при ее эксплуатации.

Такая концепция позволит вам четко разделять виды изменений в БД. А также "накатывать" изменения лишь нужных контекстов. Пример:

<changeSet id="2" author="nkoksharov" context="initdata">
        <sql>
           insert into roles values (123, 'ROLE_USER');
        </sql>
        <rollback>
            <sql>
               delete from roles where id = 123;
            </sql>
        </rollback>
</changeSet>

Если в проекте предполагается использовать две базы - БД разработчика/продакшн и БД для тестов, то pom-файл, созданного нами артефакта, будет содержать следующие строки:

<project>
  <properties>
      <liquibase.goal>update</liquibase.goal>
  </properties>
  <profiles>
 <profile>
  <id>devdb</id>
  <activation>
   <activeByDefault>true</activeByDefault>
  </activation>
  <properties>
   <database.url>${app.database.url}</database.url>
   <database.user>${app.database.user}</database.user>
   <database.password>${app.database.password}</database.password>
   <database.contexts>${app.database.contexts}</database.contexts>
  </properties>
 </profile>
    <profile>
        <id>testdb</id>
        <properties>
   <database.url>${test.database.url}</database.url>
   <database.user>${test.database.user}</database.user>
   <database.password>${test.database.password}</database.password>
   <database.contexts>${test.database.contexts}</database.contexts>
       </properties>
    </profile>
  </profiles>

  <build>
    <plugins>
      <plugin>
        <groupId>org.liquibase</groupId>
        <artifactId>liquibase-plugin</artifactId>
        <version>1.9.3.0</version>
          <configuration>
            <changeLogFile>src/main/resources/project-changelogs.xml</changeLogFile>
            <driver>org.postgresql.Driver</driver>

            <url>${database.url}</url>
            <username>${database.user}</username>
            <password>${database.password}</password>
            <contexts>${database.contexts}</contexts>
          </configuration>
          <executions>
            <execution>
              <id>appdb</id>
              <phase>process-resources</phase>
              <configuration>
                 <contexts>${app.database.contexts}</contexts>
                 <url>${app.database.url}</url>
                 <username>${app.database.user}</username>
                 <password>${app.database.password}</password>
              </configuration>
              <goals>
                 <goal>${liquibase.goal}</goal>
              </goals>
            </execution>
            <execution>
              <id>testdb</id>
              <phase>process-resources</phase>
              <configuration>
                 <contexts>${test.database.contexts}</contexts>
                 <url>${test.database.url}</url>
                 <username>${test.database.user}</username>
                 <password>${test.database.password}</password>
              </configuration>
              <goals>
                 <goal>${liquibase.goal}</goal>
              </goals>
            </execution>
          </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Параметры app.database.xxx и test.database.xxx можно определить в головном pom-файле проекта. Теперь накатывать изменения на обе БД можно одной командой:

mvn process-resources либо mvn clean install

Чтобы сделать rollback обеих баз на несколько changeset-ов назад к команде следует добавить параметры:

-Dliquibase.goal=rollback -Dliquibase.rollbackCount=1

liquibase.rollbackCount - определят кол-во changeset-ов которые следует откатить.

Порой может возникнуть ситуация, когда требуется внести изменение в существующий changeset и заново накатить все changeset-и. Здесь поможет параметр:

-Dliquibase.dropFirst=true

Если потребуется работать с каждой БД отдельно, то необходимо использовать уже команды самого плагина liquibase:

mvn liquibase:update либо mvn liquibase:rollback

Для тестовой БД добавляем параметр -Ptestdb в командной строке.

Ускорение выполнения команд maven

noreply@blogger.com (Никита Кокшаров) — Thu, 09 Jul 2009 07:33:00 +0000

На днях мне рассказали про maven-cli-plugin и я решил поспешить рассказать вам об этом окрытии. Думаю, у каждого, кто работал с maven, возникало желание хоть как-то ускорить выполнение его команд. Теперь такая возможность появилась в виде реализации выше названного плагина.

Плангин, после запуска, предоставляет разработчику командную строку, в которой вы можете запускать различные фазы жизненного цикла - clean, install, test ... (в режиме execute-phase), либо другие плагины (в режиме execute). Из-за того, что плагин, поднимает в себе инфраструктуру maven-а, то время выполнения команд, на некоторых модулях, может уменьшится в 2 раза! Первое выполнение команды может ни чем не отличаться по времени, но последующие будут быстрыми.

Я пока использую лишь execute-phase. Причем очень удобной оказалась возможность собирать несколько модулей с одной фазой, перечисляя их через пробел:

            module1 module2 clean install

Чтобы подключитьданный плагин, в pom-файле нужно указать сам плагин:

  <plugins>
        <plugin>
             <groupId>org.twdata.maven</groupId>
             <artifactId>maven-cli-plugin</artifactId>
        </plugin>
  </plugins>

И репозитарий для него:

  <pluginRepositories>
      <pluginRepository>
         <id>jboss</id>
         <name>JBoss Repository</name>
         <url>http://repository.jboss.org/maven2</url>
      </pluginRepository>
  </pluginRepositories>

Запуск выполняется командой, на уровне корневого pom-файла:

     mvn cli:execute-phase

Кстати, если вы меняете pom-файлы, то плагин придется перезапустить.

Последнее, что хотелось бы отметить - это возможность задания алиасов в коммандной строке, они указываются следующим образом:

  <plugins>
    <plugin>
       <groupId>org.twdata.maven</groupId>
       <artifactId>maven-cli-plugin</artifactId>
       <configuration>
           <userAliases>
                 <module-build>module clean install -Dpmd.skip=true -Dcheckstyle.skip=true</module-build>
                 <web-build>web-module package -Pdevelopment</web-build>
                 <rebuild>module-build web-build</rebuild>
           </userAliases>
       </configuration>
    </plugin>
  </plugins>

Javascript AOP

noreply@blogger.com (Никита Кокшаров) — Sat, 02 May 2009 13:45:00 +0000

Наверное каждому известно что такое АОП или по-просту аспектно-ориентированное программирование. В java есть целый ряд фреймворков реализующих определенные возможности данного подхода.

Но если смотреть в сторону javascript-языка, то возможности АОП в нем реализовать довольно просто:

var AOPUtils = {
    addBefore: function(object, methodName, invokedObject, invokedMethodName) {
        var oldMethod = object[methodName];
        object[methodName] = function() {
          var args = $A(arguments);
          try {
            if (Object.isFunction(invokedObject)) {
              invokedObject.call(invokedObject, args);
            } else {
              invokedObject[invokedMethodName].call(invokedObject, args);
            }
          } catch (e) {
            alert("An exception occurred in method '" + methodName + "' Error: " + e.message);
          }
          try {
            var result = oldMethod.apply(object, args);
          } catch (e) {
            alert("An exception occurred in method '" + methodName + "' Error: " + e.message);
          }
          return result;
        };
    }
};

Представленная функция AOPUtils.addBefore позволяет вам выполнить свою функцию перед функцией какого-либо объекта. Для реализации использовались стандартные javascript-функции, смысл которых состоит в следующем: apply - вызов функции с параметрами в виде массива, call - вызов функции с перечислением параметров через запятую. Первым аргументом обеих функций будет объект который в вызываемой функции будет представлять ссылку на this.

Сначала произойдет вызов вашей функции, затем функции на которую мы назначили данный аспект. Причем, в первую функцию аргументы перехваченного вызова будут переданы в виде массива, а во вторую обычным способом. Это сделано для того, чтобы наша функция, перехватывающая вызов, имела возможность переопределить значения параметров, которые идут вызываемой функции. Пример использования:

var SomeClass = Class.create({
    simplemethod: function(url) {
        alert(url);
    }
});

var sobject = new SomeClass();
AOPUtils.addBefore(sobject, "simplemethod", function(args) {
    var url = args[0];
    url += "?param=test";
    args[0] = url;
});

sobject.simplemethod("http://test.com");

Отмечу, что для использования данного механизма необоходма библиотека Prototype

Переключение из HTTPS-соединения в HTTP (в Tomcat)

noreply@blogger.com (Никита Кокшаров) — Wed, 01 Apr 2009 20:16:00 +0000

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

К примеру, если сделать на HTTPS-соединении только логин пользователя, а после его входа в систему снова использовать обычный HTTP, то на web-сервере Tomcat придется реализовать поддержку корректного переключения с HTTPS на HTTP.

Конфигурация Spring Security для такого случая:

<security:http auto-config="true" >
   <security:intercept-url pattern="/login.html" access="IS_AUTHENTICATED_ANONYMOUSLY" 
       requires-channel="https"/>
   <security:intercept-url pattern="/billing.html" access="ROLE_USER" 
       requires-channel="http"/>
</security:http>

Возможны два варианта переключения соединений:

1. 2.

В первом случае все будет работать, т.к. Tomcat создаст cookie сперва для HTTP сессии, которая будет действительна и для HTTPS, а следовательно может быть аутентифицирована Spring Security и использована дальше в работе с обычным HTTP.

Во втором случае Tomcat создаст cookie для HTTPS с параметром secure, а это значит что аутентификация такой сессии не позволит использовать в дальнейшем обычную HTTP сессию. Сookie с параметром secure привязана лишь к HTTPS-сессиям. Для пользователя же это обернется редиректом Spring Security на страницу логина, но с уже созданной cookie, и только второй логин уже пустит пользователя в систему. Чтобы решить эту проблему необходимо, находясь в HTTPS сессии, создать cookie для обычной HTTP сессии без параметра secure. С помощью фильтра это реализовать довольно просто:

package com.blogspot.nkoksharov.filter;

import java.io.IOException;

import javax.servlet.*;
import javax.servlet.http.*;

import org.apache.commons.lang.StringUtils;

public class HttpsCookieFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        final HttpServletRequest httpRequest = (HttpServletRequest) request;
        final HttpServletResponse httpResponse = (HttpServletResponse) response;
        final HttpSession session = httpRequest.getSession(false);

        if (request.isSecure() && session != null) {
            final Cookie sessionCookie = new Cookie("JSESSIONID", session.getId());
            sessionCookie.setMaxAge(-1);
            sessionCookie.setSecure(false);
            String contextPath = httpRequest.getContextPath();
            if (StringUtils.isNotBlank(contextPath)) {
                sessionCookie.setPath(contextPath);
            } else {
                sessionCookie.setPath("/");
            }
            httpResponse.addCookie(sessionCookie);
        }

        chain.doFilter(request, response);
    }

    ...

}

Теперь переход с https-соединения будет выглядеть так:

Фильтр лучше всего поместить в самом начале цепочки фильтров, важно чтобы он был перед springSecurityFilterChain. Следует отметить, что при таком решении http-cookie будет приходить пользователю на каждый https-запрос. Т.к. сложно опеределить при https-соединении создана ли cookie для http-канала.

Замена механизма отображения ошибок при валидации в Tapestry 5.1

noreply@blogger.com (Никита Кокшаров) — Mon, 30 Mar 2009 18:10:00 +0000

При унифицированном подходе к отображению ошибок на форме, обычно для каждого поля ставится соответствующий html-элемент, либо элементы в которых пользователю сообщается об ошибке в конкретном поле. К примеру, в Spring-mvc в таком случае вам придется ставить тэг form:error для каждого поля.

Механизм отображения ошибок в Tapestry 5 реализован с помощью специального декоратора, который призван избавить разработчика от расставления подобных элементов на своей странице. Реализация этого механизма находится в классе org.apache.tapestry5.internal.DefaultValidationDecorator. Результат его работы выглядит так:

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

Для этого, в модуле tapestry вашего приложения необходимо подменить markup-фильтр DefaultValidationDecorator совоей реализацией:

package com.blogspot.nkoksharov.tapestry;

import org.apache.tapestry5.*;
import org.apache.tapestry5.ioc.*;
import org.apache.tapestry5.services.*;

public class AppModule {

    public void contributeMarkupRenderer(OrderedConfiguration configuration,
                    final Environment environment) {

        MarkupRendererFilter defaultValidationDecorator = new MarkupRendererFilter() {
            public void renderMarkup(MarkupWriter writer, MarkupRenderer renderer) {
                ValidationDecorator decorator = new ExValidationDecorator(environment, writer);
                environment.push(ValidationDecorator.class, decorator);
                renderer.renderMarkup(writer);
                environment.pop(ValidationDecorator.class);
            }
        };

        configuration.override("DefaultValidationDecorator", defaultValidationDecorator);
    }
}

Логика декоратора выглядит так:

package com.blogspot.nkoksharov.tapestry;

import org.apache.tapestry5.*;
import org.apache.tapestry5.services.Environment;

public class ExValidationDecorator extends BaseValidationDecorator {

    private static final String ERROR_ELEMENT_CLASS = "error_element";

    private final Environment environment;
    private final MarkupWriter markupWriter;

    public ExValidationDecorator(Environment environment, MarkupWriter markupWriter) {
        this.environment = environment;
        this.markupWriter = markupWriter;
    }

    @Override
    public void afterField(Field field) {
        if (inError(field)) {
            String errorId = field.getClientId() + "Error";
            markupWriter.element("div",
                    "class", ERROR_ELEMENT_CLASS,
                    "id", errorId);
            markupWriter.write(getErrorMsg(field));
            markupWriter.end();
        }
    }

    private String getErrorMsg(Field field) {
        ValidationTracker tracker = environment.peekRequired(ValidationTracker.class);
        return tracker.getError(field);
    }

    private boolean inError(Field field) {
        ValidationTracker tracker = environment.peekRequired(ValidationTracker.class);
        return tracker.inError(field);
    }
}

Данный декоратор после каждого поля ставит такой вот элемент:

<div class="error_element" id="someElementError">
    Сообщение об ошибке для данного поля
</div>

Стоит отметить, что возможность переопределения элементов в списке конфигурации сервисов, через метод override стала доступна лишь начиная с версии Tapestry 5.1.0.0

Динамическое добавление bean-ов в контекст Spring

noreply@blogger.com (Никита Кокшаров) — Sun, 22 Feb 2009 08:44:00 +0000

Хорошо известно, что Spring способен создавать bean-ы из статитческого контекста. Однако, имеется возможность динамического создания и регистрации bean-ов, которая в некоторых случаях может оказаться весьма полезной. Такую функциональность предоставляет интерфейс org.springframework.beans.factory.support.BeanDefinitionRegistry метод registerBeanDefinition. Для регистрации вам понадобится объект реализующий интерфейс org.springframework.beans.factory.config.BeanDefinition. Созданием такого объекта занимается класс org.springframework.beans.factory.support.BeanDefinitionBuilder, предоставляющий практически все те же возможности конфигурации bean-а, что и в статическом xml. При регистрации bean-а, если bean c таким id уже существует, то он будет заменен.

package com.blogspot.nkoksharov;

import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.beans.factory.support.BeanDefinitionBuilder;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.testng.annotations.Test;

public class SpringTest {

    @Test
    public void testDynamicCreation() {
        ConfigurableApplicationContext context = 
             new ClassPathXmlApplicationContext("/spring/test/application-context.xml");
        BeanDefinitionRegistry factory = (BeanDefinitionRegistry) context.getBeanFactory();
        
        BeanDefinitionBuilder builder = 
             BeanDefinitionBuilder.rootBeanDefinition(com.blogspot.nkoksharov.TestBeanImpl.class);
        builder.addPropertyValue("property", "someValue");
        BeanDefinition definition = builder.getBeanDefinition();
        factory.registerBeanDefinition("testBean", definition);
        
        ... 

        TestBean bean = (TestBean) context.getBean("testBean");

        ...

    }

}

Также можно и удалять bean-ы методом removeBeanDefinition.

Сборка приложения используя maven-assembly-plugin с модулями Spring

noreply@blogger.com (Никита Кокшаров) — Thu, 19 Feb 2009 15:46:00 +0000

Столкнулся с проблемой сборки приложения при помощи maven-assembly-plugin. Напомню, что этот плагин предназначен для создания архива, включающего в себя в распакованном виде какие-либо ресурсы, а также классы из зависимостей проекта. То есть, если вам нужно поместить приложение со всеми его зависимыми классами из других библиотек в один jar-файл, то этот инструмент может вам помочь.

Однако по причине того, что плагин распаковывает все зависимости в один каталог, могу возникнуть проблемы с библиотеками, имеющими файлы с одинаковыми названиями. Именно такая ситуация и происходит, когда пытаешься собрать приложение в один jar имеющее в зависимостях spring библиотеки. После запуска приложения возникает такая ошибка:

Exception in thread "main" java.lang.IllegalStateException: 
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: 
Configuration problem: Failed to import bean definitions 
   from URL location [classpath:/spring/dao-context.xml]
Caused by: 
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: 
Configuration problem: Unable to locate Spring NamespaceHandler for 
XML schema namespace [http://www.springframework.org/schema/tx]
Offending resource: class path resource [spring/dao-context.xml]

   at org.springframework.beans.factory.parsing.
FailFastProblemReporter.error(FailFastProblemReporter.java:68)

Возникает она из-за того, что spring не может найти соответствующий NamespaceHandler предназначенный для обработки xml-схемы http://www.springframework.org/schema/tx. Соответствие между NamespaceHandler-ми и xml-схемами описывается в файле spring.handlers. Файл spring.handlers имеется в нескольких библиотеках spring (spring-aop.jar, spring-beans.jar...) в папке META-INF, таким образом в наш jar попадает лишь какой-то определенный экземпляр.При дублировании файлов maven-assembly-plugin в результате оставляет первый из них, merge-ить их он не умеет. Та же ситуация происходит и с файлом spring.schemas, в котором описываются соотвествия путей к xsd описаниям xml-схем и их реальным положением внутри библиотеки spring.

Решить возникшую проблему можно создав файлы spring.schemas и spring.handlers в папке /src/main/resources/META-INF вашего maven-проекта, агрегирующих в себе содержимое одноименных файлов из библиотек. В файле настройки maven-assembly-plugin-а необходимо указать папку /src/main/resources/META-INF которую мы будем копировать в архив, с помощью тэгов fileSets:

<assembly>
    <id>with-dependencies</id>
    <formats>
        <format>jar</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
      <fileSet>
        <directory>${basedir}/src/main/resources/META-INF</directory>
        <outputDirectory>META-INF</outputDirectory>
      </fileSet>
    </fileSets>
    <dependencySets>
        <dependencySet>
            <outputDirectory/>
            <outputFileNameMapping/>
            <unpack>true</unpack>
        </dependencySet>
    </dependencySets>
</assembly>

Таким образом наши файлы попадут в архив первыми и уже не будут перезаписаны другими вариантами из библиотек Spring.

Кстати, версию maven-assembly-plugin-а следует использовать 2.2-beta-3 и старше. Предыдующая версия будет копировать все одинаковые файлы в ваш jar, и в одной папке будет несколько файлов с одним именем.

Инструмент для просмотра логов

noreply@blogger.com (Никита Кокшаров) — Sat, 07 Feb 2009 18:46:00 +0000

В повседневной работе довольно часто приходится смотреть логи от log4j. Прежде пользовался лишь обычным view-ром, пока не нашел довольно полезный open-source инструмент MindTree Insight, предназначенный именно для этой задачи.

Из настроек отмечу лишь, то что поле Preferences -> Maintain Preferences -> Primary Pattern должно содержать ту же строку форматирования, которую вы указали в настройках log4j.

Проблема с SecurityContext-ом при invalidate http-сессии

noreply@blogger.com (Никита Кокшаров) — Mon, 02 Feb 2009 15:10:00 +0000

В Spring Security есть возможность определения допустимого числа параллельных http-сессий от одного пользователя. Как только кол-во свободных сессий исчерпает себя, то по-умолчанию самая первая из них будет уничтожена через метод invalidate() и ее место займет новая. За настройку такой возможности отвечает тэг concurrent-session-control и его параметр max-sessions.

Проблема, которая была обнаружена мной буквально на днях, следующая - при уничтожении сессии, вместо объекта org.springframework.security.context.SecurityContext приходит null. Выявить эту ошибку может следующий код:

public void onApplicationEvent(ApplicationEvent event) {
    if (!(event instanceof HttpSessionDestroyedEvent)) {
        return;
    }

    SecurityContext context = SecurityContextHolder.getContext();
    Object principal = context.getAuthentication().getPrincipal();

    ...

}

Если посмотреть порядок следования фильтров в Spring Security:

CHANNEL_FILTER
CONCURRENT_SESSION_FILTER
SESSION_CONTEXT_INTEGRATION_FILTER
LOGOUT_FILTER
...

то мы увидим, что фильтр SESSION_CONTEXT_INTEGRATION_FILTER, который как раз и выставляет нужный нам объект SecurityContext, находится после CONCURRENT_SESSION_FILTER фильтра, управляющего параллельными сессиями. Такая "неверная", в данном случае, конфигурация фильтров и приводит к потере SecurityContext-а. Потому завел на это дело багу - SEC-1092. Решения я увидел два - поменять фильтры местами, с помощью конфигурации это делается довольно просто, и выставить объект SecurityContext самому. Второй вариант мне показался более верным. Менять фильтры местами, думаю не стоит, возможно есть причина по которой они расположены именно так.

Нужный нам экземпляр SecurityContext-а можно взять из текущий http-сессии, к которой он и привязан. Хранится он в сессии по имени HttpSessionContextIntegrationFilter.SPRING_SECURITY_CONTEXT_KEY. Объект класса HttpSessionContextIntegrationFilter как раз и находится на позиции SESSION_CONTEXT_INTEGRATION_FILTER, и выставляет текущий SecurityContext в SecurityContextHolder. Сам код решения взят из этого фильтра и выглядит так:

public void onApplicationEvent(ApplicationEvent event) {
    if (!(event instanceof HttpSessionDestroyedEvent)) {
        return;
    }

    HttpSession session = event.getSession();
    SecurityContext context = (SecurityContext) session.getAttribute(HttpSessionContextIntegrationFilter.SPRING_SECURITY_CONTEXT_KEY);
    SecurityContextHolder.setContext(context);

    SecurityContext context = SecurityContextHolder.getContext();
    Object principal = context.getAuthentication().getPrincipal();

    ...

}

Генерация flex-проекта с помощью Maven

noreply@blogger.com (Никита Кокшаров) — Tue, 20 Jan 2009 09:05:00 +0000

До недавнего времени, создавать flex-проекты мне приходилось вручную. Откровенно говоря этот процесс меня не очень радовал, в результате поисков был найден maven-плагин Maven Flex Plugin.

Этот плагин помимо типичных задач компиляции swc и swf-файлов, которые способны выполнять и ряд других плагинов (например Flex-mojos), также позволяет выполнять очень ценную задачу flex:eclipse - подобие eclipse:eclipse, привычного, думаю для всех, способа геренации java-проектов под Eclipse. Для его настройки, в pom-файле необходимо зарегистрировать плагин-репозитарий:

    <pluginRepositories>
        <pluginRepository>
          <id>flex-plugin-repo</id>
          <name>Flex Plugin</name>
          <url>http://maven.servebox.org/repository/</url>
          <layout>default</layout>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
          <releases>
            <updatePolicy>never</updatePolicy>
          </releases>
        </pluginRepository>
    </pluginRepositories>

указать сам плагин:

    <plugin>
        <groupId>org.servebox.flex</groupId>
        <artifactId>flex-plugin</artifactId>
        <extensions>true</extensions>
        <inherited>true</inherited>
    </plugin>

Теперь можно выполнять: mvn flex:eclipse

Не забудьте определить переменную M2_REPO указывающую на ваш репозитарий во Flex Builder-е, на вкладке Window > Preferences > General > Workspace > Linked Resources

Плагин также регистрирует в создаваемых пректах зависимости на другие swc-библиотеки. Таким образом его достаточно запустить на уровне головного pom-файла, чтобы сгенерировать все дочерние проекты. Хочу отметить, что планиг отлично уживается в одном проекте с Flex-mojos.

С Новым Годом!!!

noreply@blogger.com (Никита Кокшаров) — Wed, 31 Dec 2008 21:48:00 +0000

Дорогие читатели, поздравляю Вас с Новым Годом!!! Хочу пожелать чтобы все мечты, загаданные под бой курантов, обязательно исполнились. Пусть рядом с Вами всегда будут хорошие люди, пусть все трудности и неприятности пройдут мимо Вас. И конечно же желаю Вам просто огромных успехов в работе.

С Новым... .-)

Миграция данных между БД

noreply@blogger.com (Никита Кокшаров) — Wed, 31 Dec 2008 12:17:00 +0000

Перемещение/преобразование данных между разными БД требует использование хорошо отлаженного механизма выполнения sql-запросов, которые необходимы для импорта/экспорта данных между БД. Написание такого рода движка потребует не мало времени и усилий.

Среди open-source решений на java мне известны два инструмента решающих подобную задачу - JDBCImporter и Scriptella. Первый инструмент делает экспорт данных сначала в xml, а затем производит из него импорт, т.е. имеет промежуточный xml при обработке данных. Сам JDBCImporter имеет утечки памяти при обработки данных больших объемов, да и как-то не активно развивается.

Scriptella - это инструмент для выполнения ETL (Extract-Transform-Load) процесса, который позволяет собирать данные из одного или нескольких источников данных и загружать их в другие позволяя выполнять различного рода трасформацию самих данных. При трансформации данных можно использовать скрипты прямо в sql-запросах, написанных на Velocity, JavaScript, JEXL... Сама конфигурация etl-процесса описывается в xml файле:

<!DOCTYPE etl SYSTEM "http://scriptella.javaforge.com/dtd/etl.dtd">
<etl>
    <description></description>
    <properties>
        <include href="script.properties"/>
        driver=org.jdcDriver
    </properties>
    <connection id="con1" driver="$driver" url="${url}" user="$user" password="12345678">
        driver.property=value
    </connection>
    <connection id="con2" url="jdbc:hsqldb:file:db" user="sa" password=""/>
    <script connection-id="out">
     <include href="dbschema.sql"/>
    </script>
    <query connection-id="in">
        SELECT * from Bug
        <script connection-id="out">
            INSERT INTO Bug VALUES (?ID, ?priority, ?summary, ?status);
        </script>
    </query>
</etl>

В описании конфигурации выделяют три основных элемента:

connection - представляет собой соединение с источником данных, таковым может являться как БД, XLS, CSV, XML... Можно также реализовать свой драйвер источника данных для Scriptella.
script - скрипт, написанный на языке источника данных к которому он относится через connection-id. Именно здесь выполняются различные скрипты на Velocity, JavaScript, JEXL и т.д.
query - запрос, выполняемый на источнике данных connection-id. Может содержать любое кол-во вложенных query и script элементов.

Запуск Scriptella можно произвести из командной строки, с помощью Ant-а, либо прямиком из Java.

Event-Driven Development в Spring. Часть 2

noreply@blogger.com (Никита Кокшаров) — Thu, 11 Dec 2008 17:26:00 +0000

Механизм рассылки event-ов в контексте Spring реализован одним интерфейсом org.springframework.context.event.ApplicationEventMulticaster. Именно ему и будут делегироваться все добавления, удаления listener-ов, а также публикация event-ов для них. По-умолчанию, в качестве реализации такого интерфейса будет использоваться объект класса org.springframework.context.event.SimpleApplicationEventMulticaster. В самом же контексте данный bean регистрируется под именем applicationEventMulticaster. Однако, если под таким именем bean уже существует и реализует нужный интерфейс, то будет использоваться именно он.

Необоходимость создания своего ApplicationEventMulticaster-а может возникнуть, например, чтобы рассылать event-ы по spring-контекстам целого кластера. Именно этот случай и реализован в моем примере. Сам механизм коммуникации между нодами обеспечивается фреймворком JGroups, который рассылает сообщения по сети multicast-ом через UDP-протокол. Объект com.blogspot.nkoksharov.springevents.jgroups.JGroupsMulticaster переопределяет метод void multicastEvent(ApplicationEvent event) и рассылает по сети лишь те экземпляры event-ов, классы которых являются подклассами com.blogspot.nkoksharov.springevents.jgroups.JGroupsEvent. А вот и сам код JGroupsMulticaster-а:

package com.blogspot.nkoksharov.springevents.jgroups;

import org.jgroups.*;
import org.slf4j.*;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.context.ApplicationEvent;
import org.springframework.context.event.SimpleApplicationEventMulticaster;

/**
 * Alternative multicaster to org.springframework.context.event.SimpleApplicationEventMulticaster
 *
 * @author nkoksharov
 *
 */
public class JGroupsMulticaster extends SimpleApplicationEventMulticaster    implements InitializingBean, DisposableBean, LocalEventMulticaster {

   private final Logger logger = LoggerFactory.getLogger(getClass());
   private JChannel jchannel;
   private JGroupsReceiver receiver = new JGroupsReceiver();
   private String configFile;
   private String clusterName;

   public void multicastEvent(ApplicationEvent event) {
      if (event instanceof JGroupsEvent) {
          try {
             jchannel.send(new Message(null, null, event));
          } catch (ChannelNotConnectedException e) {
             logger.error("channel not connected", e);
          } catch (ChannelClosedException e) {
             logger.error("channel closed", e);
          }
      } else {
          super.multicastEvent(event);
      }
   }

   public void localMulticastEvent(JGroupsEvent event) {
      super.multicastEvent(event);
   }

   public void afterPropertiesSet() throws Exception {
      jchannel = new JChannel(configFile);
      receiver.setLocalMulticater(this);
      jchannel.setReceiver(receiver);
      jchannel.connect(clusterName);
   }

   public void destroy() throws Exception {
      jchannel.close();
   }
   public void setConfigFile(String configFile) {
      this.configFile = configFile;
   }
   public void setClusterName(String clusterName) {
      this.clusterName = clusterName;
   }
}

Рассылка же абсолютно всех event-ов, в частности системных, может привести к некорректной работе всего spring-контекста.

Проект собирается с помощью Maven-а и запускается командой:

mvn compile exec:java

Каждый запуск - это новый контекст, т.е. можно запустить приложение на разных компьютерах в локальной сети и наблюдать появление сообщений в консоли о получении event-ов. Также можно запустить несколько экземпляров приложения на одном компьютере, все должно работать.

Скачать исходники
Event-Driven Development в Spring. Часть 1

Rhino и Janino для вычисления математических выражений

noreply@blogger.com (Никита Кокшаров) — Mon, 01 Dec 2008 17:17:00 +0000

Для вычисления математических формул в run-time можно воспользоваться script-движком реализующим JSR-223. В Java 1.6 реализация этой спецификации представлена javascript-движоком Rhino. Однако применение целого script-движка для обычного вычисления формул будет довольно неоправданным решением. Мой поиск привел к Janino - это целый фреймворк для динамической компиляции и исполнения java. То есть он позволяет выполнять скрипты на java внутри самой java. Одно из его призваний это компиляция и выполнение различных математических выражений с помощью org.codehaus.janino.ExpressionEvaluator.

Я решил сравнить производительность Rhino и Janino. Для теста выбрал простую формулу: (x-10)*Math.sin(0.1)*2, вычисление которой будет осуществляться 1000000 раз.

package com.blogspot.nkoksharov;

import javax.script.*;

import org.apache.commons.lang.time.StopWatch;
import org.codehaus.janino.ExpressionEvaluator;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.ContextFactory;
import org.mozilla.javascript.Function;
import org.mozilla.javascript.Scriptable;
import org.testng.annotations.Test;

public class ExpressionTest {

    @Test
    public void testRhino() throws ScriptException {
        ScriptEngineManager scriptManager = new ScriptEngineManager();
        ScriptEngine se = scriptManager.getEngineByName("JavaScript");
        SimpleBindings bindings = new SimpleBindings();
        bindings.put("x", 2);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double result = (Double) se.eval("(x-10)*Math.sin(0.1)*2", bindings);
        }
        stopWatch.stop();
        System.out.println("JDK Rhino time: " + stopWatch);
    }

    @Test
    public void testRhinoFunc() throws ScriptException, NoSuchMethodException {
        ScriptEngineManager scriptManager = new ScriptEngineManager();
        ScriptEngine se = scriptManager.getEngineByName("JavaScript");

        String script = "function count(x) { return (x-10)*Math.sin(0.1)*2; }";
        se.eval(script);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Invocable inv = (Invocable) se;
            Double result = (Double) inv.invokeFunction("count", 2);
        }
        stopWatch.stop();
        System.out.println("JDK Rhino func time: " + stopWatch);
    }

    @Test
    public void testNativeRhinoCompiledFunc() {
        ContextFactory cf = new ContextFactory();
        Context cx = cf.enterContext();
        Scriptable scope = cx.initStandardObjects();
        Function f = cx.compileFunction(scope, "function count(x) { return (x-10)*Math.sin(0.1)*2; }", null, 0, null);

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double value = (Double) f.call(cx, scope, scope, new Object[] {2});
        }
        stopWatch.stop();
        System.out.println("Mozilla Rhino compiled-func time: " + stopWatch);
    }

    @Test
    public void testJanino() throws Exception {
        ExpressionEvaluator ee = new ExpressionEvaluator("(x-10)*Math.sin(0.1)*2",
            Double.class, new String[] {"x"}, new Class[] {Integer.class});

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        for (int i = 0; i < 1000000; i++) {
            Double result = (Double) ee.evaluate(new Object[] {2});
        }
        stopWatch.stop();
        System.out.println("Janino time: " + stopWatch);
    }
}

Результат вполне оправдал мои ожидания:

                                 (ч:мм:сс.мс)
                  JDK Rhino time: 0:01:50.061
             JDK Rhino func time: 0:00:59.040
Mozilla Rhino compiled-func time: 0:00:00.344
                     Janino time: 0:00:00.156

В итоге получается, что скорость выполнения с Rhino использующейся в JDK заметно отстает от Janino, даже не смотря на выполнение через javascript-функцию. Однако, если вы будете использовать реализацию Rhino от Mozilla, с возможностью компиляции в bytecode, то получите лишь 2-х кратное отставание по скорости. И так первенство у Janino, который также компилирует выражения перед выполнением. При этом обращения к методу ExpressionEvaluator.evaluate будут thread-safe.

Генерация javabean в runtime

noreply@blogger.com (Никита Кокшаров) — Wed, 19 Nov 2008 19:52:00 +0000

Если требуется создать javabean в runtime по набору полей, то никакими стандартными средствами java эту задачу решить не удастся.

По началу я решил, что с этой задачей может справиться какая-либо из реализаций org.apache.commons.beanutils.DynaBean. Однако работать с ним можно лишь так if (object instanceof DynaBean) ... . То есть, если модуль использующий этот объект работает с ним только через reflection и ничего не знает о DynaBean, то такое решение не подходит.

В итоге, было решено использовать Javassist. Очень удобный инструмент для подобного рода действий, позволяет производить как создание так и модификацию уже загруженных JVM классов. Предоставляет два вида API, на уровне исходного кода и собственно самого байткода. Использовать конечно лучше первый, т.к. мало кого устроит работать напрямую с байткодом.

В альтернативу classloader-у используется класс javassist.ClassPool, он позволяет не только загружать, но и создавать классы javassist.CtClass. При этом класс не будет доступен приложению сразу же, а лишь после преобразования в обычный класс java.lang.Class. Сам javassist.CtClass обладает богатыми возможностями для создания, удаления методов и полей, изменения наследования или даже названия уже загруженного класса. Для доступа ко всем классам загруженным JVM следует использовать ClassPool.getDefault(), хотя можно реализовать и свой, чтобы, например, загружать классы самостоятельно.

Итак, решение с использованием Javassist будет выглядеть так:

public Class<?> createClass(String className, Map<String, Class<?>> props) throws Exception {
 ClassPool classPool = ClassPool.getDefault();
 CtClass cc = classPool.makeClass(className);
 
 for (Entry<String, Class<?>> entry : props.entrySet()) {
  String name = entry.getKey();
  Class<?> type = entry.getValue();
  CtClass fieldType = classPool.get(type.getName());
  CtField field = new CtField(fieldType, name, cc);
  cc.addField(field);
  
  String n = camelize(name);
  CtMethod setter = CtNewMethod.setter("set" + n, field);
  cc.addMethod(setter);
  CtMethod getter = CtNewMethod.getter("get" + n, field);
  cc.addMethod(getter);
 }
 
 return cc.toClass();
}
 
private String camelize(String s) {
 return s.substring(0, 1).toUpperCase() + s.substring(1);
}

Log4jdbc логгер для sql-запросов

noreply@blogger.com (Никита Кокшаров) — Sun, 16 Nov 2008 15:59:00 +0000

Log4jdbc представляет собой jdbc-драйвер, который может логировать sql-вызовы используя SLF4J. Реализует как JDBC 3 так и JDBC 4 спецификации. Для настройки к вашему jdbc-url необходимо просто добавить префикс jdbc:log4. Например:

jdbc:postgresql://localhost:5432/test, заменить на jdbc:log4jdbc:postgresql://localhost:5432/test

Затем в log4j.xml или log4j.properties настроить logger на любую из категорий:

jdbc.sqlonly - логирование только sql запросов,
jdbc.sqltiming - логирование sql-запросов и их времени выполнения,
jdbc.audit - логирование всех jdbc-операций за исключением ResultSet-ов,
jdbc.resultset - самое полное логирование, включающее в себя операции со всеми ResultSet-объектами,
jdbc.connection - логирование операций с jdbc-соединениями

Отключение кэширования html-страницы. Часть 2

noreply@blogger.com (Никита Кокшаров) — Wed, 12 Nov 2008 04:20:00 +0000

Использование meta-тэгов, описываемых в первой части помогает нам избавиться от кэширования в браузере. Однако, помимо кэша браузера существует кэш прокси-сервера, который проводит анализ лишь HTTP-заголовков. К тому же может появится необходимость отключить кэширование не только самой html-страницы, но и ресурсов, находящихся на ней (jpg, swf ...). Данную проблему можно решить таким вот servlet-фильтром:

package ru.someone;

import java.io.IOException;
import java.util.*;
import javax.servlet.*;
import org.slf4j.*;

public class ResponseHeaderFilter implements Filter {

    private final Logger log = LoggerFactory.getLogger(getClass());
    private final Map httpParams = new HashMap();

    public void init(FilterConfig filterConfig) throws ServletException {
        Enumeration enums = filterConfig.getInitParameterNames();
        while(enums.hasMoreElements()) {
            final String name = enums.nextElement();
            final String value = filterConfig.getInitParameter(name);
            log.debug("HTTP-header registred - {}:{}", name, value);
            httpParams.put(name, value);
        }
    }

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse httpResponse = (HttpServletResponse) response;
        for (Entry entry : httpParams.entrySet()) {
            httpResponse.setHeader(entry.getKey(), entry.getValue());
        }
        chain.doFilter(request, response);
    }

    public void destroy() {
    }

}

Этот фильтр выставляет HTTP-заголовки, объекту javax.servlet.HttpServletResponse, которые берет из конфигурации фильтра. Соответственно в самом web.xml нужно написать:

<filter>
     <filter-name>responseHeaderFilter</filter-name>
        <filter-class>ru.someone.ResponseHeaderFilter</filter-class>
        <init-param>
            <param-name>Cache-Control</param-name>
            <param-value>no-store, max-age=0, must-revalidate</param-value>
        </init-param>
        <init-param>
            <param-name>Pragma</param-name>
            <param-value>no-cache</param-value>
        </init-param>
        <init-param>
            <param-name>Expires</param-name>
            <param-value>Fri, 01 Jan 1990 00:00:00 GMT</param-value>
        </init-param>
</filter>
<filter-mapping>
     <filter-name>responseHeaderFilter</filter-name>
     <url-pattern>*.jpg</url-pattern>
</filter-mapping>
<filter-mapping>
     <filter-name>responseHeaderFilter</filter-name>
     <url-pattern>*.swf</url-pattern>
</filter-mapping>

Slf4j на смену commons-logging

noreply@blogger.com (Никита Кокшаров) — Sun, 09 Nov 2008 19:00:00 +0000

Наверное каждый из вас знаком с commons-logging. Однако пользы от него не так много. Наличие трюков с class-loader-ами, а также излишнее использование reflection-а и отсутствие возможности использования параметризированных сообщений, мягко говоря огорчают.

Довольно популярной заменой commons-logging является Slf4j (Simple Logging Framework for Java). Во-первых, в нем реализована поддержка MDC (пока что такая возможность реализована в logback и log4j). Этот механизм удобно использовать, когда у вас в контексте одного потока в лог записывается много параметра, которые действительны только для данного контекста. Например, для каждого сообщения необходимо выводить также имя пользователя, его логин и т.д. Вместо того чтобы указывать эти параметры каждый раз в сообщении. Можно положить их в MDC-контекст:

MDC.put("ipAddress", request.getRemoteAddr());
Principal user = request.getUserPrincipal();
MDC.put("user", user.getName());

И указать в ConversionPattern log4j эти параметры:

%X{ipAddress} - %X{user} %n%m

Во-вторых, есть наличие параметризованных сообщений. То есть, если раньше надо было писать так:

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));

Если у нас будет не debug уровень, то будет тратиться время на сборку строки, которая не будет выводиться. Потому надо будет написать так:

if(logger.isDebugEnabled()) { 
     logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}

Используя Slf4j все это можно заменить одной строкой:

logger.debug("Value {} was inserted between {} and {}.", 
     new Object[] {newVal, below, above});

Символами {} как раз и обозначаются параметры строки, которые передаются последним аргументом. При этом сборка строки не будет производиться при уровне ниже чем debug.

В-третьих, сама архитектура представляет собой два модуля, api slf4j-api.jar и реализация slf4j-XXXXX.jar. Реализация представлена 6-ью модулями:

На главной странице этого проекта перечислены проекты, которые используют данный фреймворк и их число растет.

Пример использования:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

class TestClass {

 private final Logger log = LoggerFactory.getLogger( TestClass.class ); 

 ...

 log.debug( "..." );
}

Кто такой javaagent?

noreply@blogger.com (Никита Кокшаров) — Tue, 04 Nov 2008 13:00:00 +0000

У Java-машины есть один интересный параметр -javaagent. О нем почему-то весьма мало сказано в документации по самой JVM, есть лишь описание в javadoc java.lang.instrument. Сам параметр появился начиная с Java 1.5, и позволяет получать доступ к механизму манипулирования с байт-кодом классов (трансформация, переопределение классов).

В командной строке он выглядит так:

    -javaagent:jarpath[=options]

где jarpath - путь к jar-нику содержащему класс agent-а, и options - строка доп. параметров agent-а, передается при его вызове.

Сам параметер может содержаться несколько раз в строке параметров JVM, позволяя загружать несколько agent-ов. Указываемый JAR должен удовлетворять спецификации JAR-файла, т.е. иметь манифест файл META-INF/MANIFEST.MF, со следующими возможными атрибутами:

Premain-Class (обязательный) - он содержит имя класса agent-а с premain методом.
Boot-Class-Path - содержит как абсолютные так и относительные пути поиска классов, для Bootstrap classloader-а. Относительный путь начинается от абсолютного пути самого JAR-файла. Пути могут указывать как на директорию, так и на jar-библиотеку. В качестве разделителя используются пробел. Эти пути будут использоваться в случае, если какие-то классы не были найдены стандартными механизмами Java.
Can-Redefine-Classes - указывает возможность переопределения классов, может иметь значение true, либо false (по-умолчанию).
Can-Retransform-Classes (только в Java 1.6) - указывает возможность ретрансформации классов, может иметь значение true, либо false (по-умолчанию).

Метод premain, может иметь одну из следующих сигнатур:

public static void premain(String agentArgs, Instrumentation inst);

public static void premain(String agentArgs); (только Java 1.6)

В agentArgs передается сама строка options, разработчик должен сам реализовать логику парсинга этой строки, если хочет передавать в ней несколько аргументов. Собственно сам интерфейс java.lang.instrument.Instrumentation и предоставляет нам доступ к механизмам операций с байт-кодом. Сам метод premain вызывается, как вы уже должно быть поняли, еще до выполнения метода main приложения.

public class InstrumentExample {

    private static Instrumentation inst;

    public static void premain(String options, Instrumentation inst) {
        inst.addTransformer(new SomeTransformer());
        this.inst = inst;
    }

    public static void main(String args[] ) {
     
        ...

        byte[] classBytes = ...
        ClassDefinition classDef = new ClassDefinition(SomeClass.class, classBytes);
        inst.redefineClasses(classDef);

        ...
        
    }

    public static class SomeTransformer implements ClassFileTransformer {
        public byte[] transform(java.lang.ClassLoader loader,
                java.lang.String className,
                java.lang.Class classBeingRedefined,
                java.security.ProtectionDomain protectionDomain,
                byte[] classfileBuffer) throws IllegalClassFormatException
        {
            ...
        }
    }

    ...
}

Чтобы использовать механизм трансфорамации классов вам нужно реализовать интерфейс java.lang.instrument.ClassFileTransformer. И зарегистрировать свою реализацию через метод Instrumentation.addTransformer. Сам трасформер будет срабатывать каждый раз при:

загрузке класса ClassLoader.defineClass
переопределении класса Instrumentation.redefineClasses
ретрансформации класса Instrumentation.retransformClasses.

Аргумент classfileBuffer содержит байт-код текущей версии класса, и его нельзя модифицировать, для его переопределения трансформер должен вернуть новый массив байт, либо null, если трансформация не была произведена. В случае, когда трансформеров несколько, то они будут вызваны по цепочке, при этом classfileBuffer будет результатом предыдущего трансформера. Чтобы сообщить об ошибке при трансформации необходимо выбросить java.lang.instrument.IllegalClassFormatException, при unchecked-ошибках результат будет такой, как если бы метод вернул null.

Для переопределения класса необходимо указать выше описанный параметер в манифесте и использовать класс java.lang.instrument.ClassDefinition. Только вот есть ограничения: переопределение класса не должно добавлять, удалять новые поля или методы, менять сигнатуру методов или иерархию наследования. Можно менять только тело методов, структура класса меняться не должна. Если в приложении уже используются экземпляры предыдущей версии класса, то с ними ничего не произойдет, однако при последующем создании класса, будет использована уже новая версия.

К сожалению, Java-платформа не предоставляет стандартных инструментов для модификации/генерации байт-кода. В этом случае можно воспользоваться уже готовыми фреймворками, например, Javaassist или BCEL.

Javaаgent реализован в фреймворке Spring, чтобы можно было использовать AOP для классов, вне контекста. Тестовый фреймворк Jmockit также реализует своего javaagent-а. Тем самым открывая возможность писать mock-и для классов, экземпляры которых вы не можете заменить обычными способами, либо они содержат статические методы, заменить которые возможно только до загрузки класса.

Event-Driven Development в Spring. Часть 1

noreply@blogger.com (Никита Кокшаров) — Fri, 31 Oct 2008 13:52:00 +0000

Еще в Spring 1.2 была возможность посылать различные event-ы через весь контекст приложения. Я считаю этот вид коммуникации в некоторых местах приложения единственным верным решением.

Опишу кратко как работает этот механизм. Базовым классом для event-а должен быть org.springframework.context.ApplicationEvent, для рассылки которого используется метод org.springframework.context.ApplicationContext.publishEvent(event). Ну а получать event-ы будут те bean-ы, которые реализуют интерфейс org.springframework.context.ApplicationListener с единственным методом onApplicationEvent(event).

Допустим, что у нас есть логика, после выполнения которой другим сервисам необоходимо также сделать какие-то действия. Стандартный вариант решения такой задачи предполагает использование IoC:

public class BussinesServiceImpl implements BussinesService {

    @Autowired
    private EmailService emailService;
    @Autowired
    private LoggingService logService;
    
    public void doAction() {
        
        ...
        
        emailService.sendEmail(email, body);
        logService.recordLog(data);
    }
}

Также можно использовать и аспекты. Только вот получать параметры, которые пришли не через аргументы метода, advice-ам будет сложно. Реализовать такой случай с помощью event-ов можно так:

public class BussinesServiceImpl implements BussinesService, ApplicationContextAware {

    private ApplicationContext context;
    
    public void doAction() {
        
        ...
        
        ActionEvent event = new ActionEvent();
        event.setEmail(email);
        event.setEmailBody(body);
        event.setData(data);
        context.publishEvent(event);
    }

    public void setApplicationContext(ApplicationContext value) {
        context = value;
    }
}

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

public class EmailServiceImpl implements EmailService, ApplicationListener {

    ...

    public void onApplicationEvent(ApplicationEvent event) {
        if (!(event instanceof ActionEvent)) {
            return;
        }

        ActionEvent actionEvent = (ActionEvent) event;
        sendEmail(actionEvent.getEmail(), actionEvent.getEmailBody());
    }
}

public class LoggingServiceImpl implements LoggingService, ApplicationListener {

    ...

    public void onApplicationEvent(ApplicationEvent event) {
        if (!(event instanceof ActionEvent)) {
            return;
        }

        ActionEvent actionEvent = (ActionEvent) event;
        recordLog(actionEvent.getData());
    }
}

Какое преимущество дает такой подход? Изоляцию сервиса, от лишних зависимостей. Такая изоляция дает возможность выносить сервисы типа BussinesService в отдельные модули, которые не потребуют в дальнейшем модификации, если понадобится добавить вызов какого-либо сервиса.

Идентификация пользователя в браузере. Как узнать IP и MAC в Java-апплете.

noreply@blogger.com (Никита Кокшаров) — Wed, 29 Oct 2008 19:23:00 +0000

Задача: необходимо чтобы пользователь, с одного компьютера, имел лишь одну сессию с сервером.

При этом нужно учитывать, что пользователь может использовать разные браузеры, так что зацепка за какой-нибудь параметр http-заголовока типа User-agent ничего не даст. Однако возможно получить реальный ip-адрес клиента в подсети, а не возможного прокси, который мы получаем через HttpServletRequest.getLocalAddr(). Редко сейчас у клиентов есть выделенные ip. Также, помимо ip можно получить и mac-адрес! Все что для этого нужно так это написать Java-Applet, который запустится у клиента в браузере и передаст нужную нам информацию.

Вообще возможность определение ip адреса во внутренней сети пришла в голову некому Lars Kindermann-у в 2002-ом году. Судя по фотке он проживает где-то на полярном круге .-) Его идея оказалась принципиально простой. Java-Applet создает подключение к серверу, с которого его скачали, через объект java.net.Socket. В результате мы легко можем получить сетевую информацию о клиенте.

Ну а чтобы получить mac-адрес, не придется даже создавать соединения, можно просто сделать вызов java.net.NetworkInterface.getHardwareAddress(). Можно было бы довольствоваться лишь mac адресом. Однако, возможность его получения появилась лишь в JRE 1.6.

В решении я использовал, как обычно, Spring Security 2.0.4. Идея следующая, после аутентификации пользователя мы проверяем есть ли такой же клиент, с тем же ip и mac-ом, уже в системе. Для этого необходимо, чтобы фильтр аутентификации перебросил нас на страничку с апплетом. Затем уже апплет собирает сетевую информацию о клиенте и отсылает ее на сервер простым GET-ом, в ответ на этот запрос, сервер, выполнив проверку, посылает редирект на следующую страничку, либо выдает ошибку. При получении запроса сервером, составляется композитный id клиента, в нем учавствует как mac и локальный ip клиента, пришедшие от апплета, так и ip шлюза с которым соединен сервер и за которым находится сам клиент. Я свел воедино оба решения, использовать нужно либо ip+ip шлюза, либо mac вместе их использовать уже избыточно. Если есть возможность, и в требованиях вашего приложения предусмотрена возможность установки JRE 1.6 на машину клиента, то лучше использовать mac. Способ идентификации основанный только на ip имеет недостаток. В случае если за одним шлюзом может находится несколько подсетей, а следовательно и клиентов с одинаковым адресом может быть тоже несколько.

Вот собственно и сам исходный код апплета:

import java.applet.Applet;
import java.net.NetworkInterface;
import java.net.Socket;
import java.net.SocketException;
import java.net.URL;
import java.util.Enumeration;

public class UserApplet extends Applet {

    /**
     * Запуск апплета
     */
    public void start() {
        String remoteHost = getDocumentBase().getHost();
        int remotePort = getDocumentBase().getPort();
        String ip = getLocalIp(remoteHost, remotePort);
        String mac = getLocalMac();
        sendInfo(ip, mac);
    }

    /**
     * Получение локального mac
     */
    private String getLocalMac() {
        try {
            Enumeration nis = NetworkInterface.getNetworkInterfaces();
            while(nis.hasMoreElements()) {
                String mac = macToString((NetworkInterface) nis.nextElement());
                if (mac != null) {
                    return mac;
                }
            }
        } catch (SocketException e) {
            showStatus("");
        }
        return null;
    }

    private static String macToString(NetworkInterface ni)
            throws SocketException {
        byte mac[] = ni.getHardwareAddress();
        if(mac != null) {
            StringBuffer macAddress = new StringBuffer();
            String sep = "";
            for (int i = 0; i < mac.length; i++) {
                int b = Math.abs(mac[i]);
                String hexByte = Integer.toHexString(b);
                macAddress.append(sep).append(hexByte);
                sep = ":";
            }
            return macAddress.toString();
        }
        return null;
    }

    /**
     * Получение локального ip
     */
    private String getLocalIp(String remoteHost, int remotePort) {
        Socket socket = null;
        try {
            socket = new Socket(remoteHost, remotePort);
            String localIp = socket.getLocalAddress().getHostAddress();
            return localIp;
        } catch (Exception e) {
            showStatus("");
        } finally {
            if (socket != null) {
                socket.close();
            }
        }
        return "unknown";
    }

    /**
     * Отправляем информацию об ip и mac
     */
    private void sendInfo(String ip, String mac) {
        try {
            URL url = new URL(getDocumentBase(), "/userInfo?ip=" + ip + "&mac=" + mac);
            getAppletContext().showDocument(url, "_self");
        } catch (Exception e) {
            showStatus("");
        }
    }
};

Апплет загружает ответом нашего Spring Security фильтра ru.someone.UserInfoFilter содержимым:

<applet code="UserApplet.class" codebase="/" codetype="application/java" width="0" height="0"></applet>

После чего этот же фильтр делает необходимую проверку и посылает ответ. При логауте из системы, данные о клиенте удаляются вместе с его сессией. Чтобы это действительно было так, в web.xml нужно прописать listener: org.springframework.security.ui. session.HttpSessionEventPublisher. Который будет посылает эвенты об удалении сессии по всему Spring-контексту, а наш ru.someone.UserInfoFilter будет их получать.

Исходники можно взять здесь