Пишем планировщик на Java

Недавно возникла необходимость чтобы приложение в назначеное время выполняло работу по поддержке своей базы (обновляло информацию). Конечно можно было написать маленькую утилитку и вызывать её из крона, но этот вариант показался неудобным в поддержке - сервер приложений может переезжать и настраивать на каждом новом сервер крон желания не было, т.е. хотелось бы чтобы приложение само себя обслуживало, без лишних телодвижений.

К счастью существует несколько способов создать свой планировщик в enterprise-приложении. Об одном из них (а именно как это сделать с помощью ServletContextListener) я далее и расскажу.

Java MongoDB Tutorial

Сначала я хотел написать заметку, в которой бы вкраце излогались основные моменты работы с MongoDB, но потом понял, что официальный Java QuickTour уже удовлетворяет всем моим требованиям к конспекту по технологии, так что я решил просто сделать перевод данного руководства. Итак, начнем.

Основы JDBC

JDBC (Java DataBase Connectivity) - очень простая технология, обеспечивающая вашему приложению связь с базой данных. Даже если вы не планируете использовать её напрямую, то в любом случае было бы полезно знать как на самом деле работает ваш любимый фреймворк для БД.
В данной заметке мне бы хотелось пройтись по всем методам технологии, которые вероятнее всего вы будете использовать при написании своего приложения. Начнем с установки соединения.

RIA: GWT или Vaadin

В последнее время веб-приложения приобрели огромную популярность. RIA (Rich Internet Application) - это нечто большее, чем просто сайт. Это практически полноценное приложение, которое запускается в браузере. Плюсов переноса своих десктоп-приложений в веб множество: это и платформонезависимость, и расширяемость, и оперативное исправление ошибок. Однако и минусов тоже хватает и в первую очередь стоит отметить сложность обеспечения корректной работы приложения в разных браузерах.

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

В языке java существует два фреймворка, которые можно считать стандартами в разработке RIA-приложений: GWT и Vaadin. Рассмотрим чуть подробнее каждый из них.

Декларативные транзакции в Hibernate

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

Основы EJB: часть 1

Сервер приложений j2ee состоит из двух основных элементов: контейнер web-приложения (JSP, JSF и т.д.) и EJB-контейнер. Первый служит для создания пользовательского интерфейса и слабо подходит для описания бизнес-логики приложения. Для этого используется вторая часть J2EE - EJB.

Технологию EJB (Enterprise Java Beans) можно рассматривать с двух точек зрения: как фреймворк, и как компонент.
С точки зрения компонента EJB - это всего-лишь надстройка над POJO-классом, описываемая с помощью аннотации. Существует три типа компонентов EJB:

1. session beans - используется для описания бизнесс-логики приложения
2. message-driven beans - так же используется для бизнесс-логики
3. entities - используется для хранения данных

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

Перед тем, как продолжить обзор основ EJB остановимся на основе любого приложения - архитектуре.

Удаление всех таблиц из БД

Иногда возникает необходимость удалить все таблицы. Конечно, проще удалить пользователя базы и создать его заново. Это самый надёжный вариант, который точно удалит весь мусор, который может остаться в базе, однако не всегда на это есть пермиссии. Но можно воспользоваться этим скриптом:

BEGIN
  FOR i IN (SELECT table_name FROM user_tables)
    LOOP
      EXECUTE IMMEDIATE('DROP TABLE ' || user || '.' || i.table_name || ' CASCADE CONSTRAINTS');
    END LOOP;
END;

А тут еще 2 полезных скрипта:

Фильтры в web-приложениях

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

Фильры запроса могут использоваться для: проведения дополнительных проверок безопасности, форматирования заголовка или тела запроса, ведения логов и т.д.
Фильтры ответа могут использоваться для: сжатия выходного потока, дополнять или подменять выходной поток и т.д.
И фильтр запроса, и фильтр ответа используют при реализации  один интерфейс – Filter.

Пример декларации фильтра в дескрипторе развертывания:

    MyAppRequest
    com.example.myapp.myappRequest
    
        LogFileName
        UserLog.txt
    


    MyAppRequest
    *.do

Вместо <url-pattern> можно было указать <servlet-name> и использовать фильтр к какому-то конкретному сервлету.

Реализация фильтра для данного примера может быть такой:

public class myappRequest implements Filter {
    private FilterConfig fc;
    private void init(FilterConfig config) throws ServletException {
        this.fc = config;
    }
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException, IOException {
        HttpServletRequest httpReq = (HttpServletRequest) req;
        String name= httpReq.getRemoteUser();
        if( name!= null )
            fc.getServletContext().log(“User: “ +name);
        chain.doFilter(req,resp);
    }
    public void destroy() {}
}

Безопасность web-приложения

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

Аутентификация
Настройка листа пользователей, имеющих доступ к работе с приложением, зависит от контейнера, который вы используете. К примеру, для Apache Tomcat нужно модифицировать файл tomcat-users.xml, который расположен по адресу $TOMCAT/conf. Например, он может выглядеть так:

<tomcat-users>
    <role rolename=”Admin”/>
    <role rolename=”User”/>
    <user username=”root” password=”toor” roles=”Admin, User” />
    <user username=”user” password=”resu” roles=”User” />
</tomcat-users>

Имена ролей чувствительны к регистру.
Для того чтобы аутентификация работала, нужно в дескрипторе развёртывания написать:

<login-config>
    <auth-method>BASIC</auth-method>
</login-config>

И указать какие роли мы хотим использовать в приложении:

<security-role><role-name>Admin</role-name></security-role>
<security-role><role-name>User</role-name></security-role>

Основные тэги JSTL (JSP Standard Tag Library)

Перед тем, как начать описывать тэги думаю не лишним будет еще раз напомнить как же подключается сам JSTL. А подключается он следующей строчкой:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Тэг <c:out>
Используется для вывода данных на экран. Лучше, чем вывод типа ${pageContext.parameter}  тем, что позволяет контролировать специальные символы html, такие как <, >, &, ‘ и “. За то будут ли они обработаны как html или просто показаны на экране отвечает свойство escapeXml, которое по умолчанию стоит в true. Пример:

<c:out value=’${pageContext.parameter}’ escapeXml=’false’ />

Если в value будет null, то c:out выведет на экран пустое место, но если задать значение аттрибута по-умолчанию, то выведется оно. Например:

<c:out value=’${user}’ default=’guest’ />

напечатает имя пользователя, если оно есть или guest, если пользователь не задан.
Или можно написать так:

<c:out value=’${user}’>guest</c:out>

Упаковка по функциональности, а не по слоям

Перевод статьи «Package by feature, not layer».

Первый вопрос при проектировании нового приложения – «Как упаковать его по пакетам?». Для обычных приложений существует два ответа на этот вопрос.

Упаковка по функциональности (Package-by-feature)

Паттерн Package-by-feature подразумевает использование пакетов для отражения фунциональности. Предпологается, что все классы, относящиеся к некоторой функциональности (и только они) упаковываются в один каталог/пакет. В результате мы получаем пакеты с высокой степенью связанности и модульности с одной стороны, и минимальной связью с остальными пакетами с другой. Элементы приложения, которые тесно взаимодействуют друг с другом, находятся в непосредственной близости и не расползаются по всему приложению. В некоторых случаях, удаление части фунционала сводится только к одной операции – удалению каталога. (Операция удаления может быть хорошим показателем степени модульности элемента приложения: максимальная модульность возможна только в том случае, если элемент может быть удален используя только одну операцию.)

Конспект "Hibernate reference manual"

Данная заметка не является мини-учебником или пошаговым руководством по написанию простого приложения с использованием Hibernate, но её можно воспринимать как шпаргалку, позволяющую быстро освежить в памяти знания по данному фреймоврку у тех, кто ими уже обладает, и помочь начинающим программистам, мало работавших с фреймворком, упорядочить свои знания "по полочкам".