Игорь Артамонов

Бывает что при обновлении версии работающего приложения тратится иногда по нескольку часов на приведение структуры БД к новому виду. Ну т.е. добавление колонок, переименовывание, смена связей и пр. При этом DBA сидит и по diff двух инициализационных sql (для текущего приложения и для нового) пытается понять что менялось и как нужно прописать все эти ALTER TABLE ..., или того хуже UPDATE по хитрым условиям. Когда то, по неопытности, и мы так делали, при этом приложение клиента ждало (т.е. не работало) иногда по нескольку часов. Слава богу у них в это время была ночь и заказчик сладко спал, иначе бы много чего могли бы наслушаться.
Читать далее »»

При редактировании объекта через форму есть потенциальная уязвимость в системе, т.е. даже если мы в самой форме не указали внутренние поля (id, role, и пр) то хакер всегда может передать их в запросе сам. Конечно ему нужно знать какие поля есть в объекте, что бы передать для них значения, но это отнюдь нас не защищает. Некоторые интересные поля можно найти перебором по словарю.

Так вот, я к тому что Spring предоставляет возможность указать какие поля позволено менять извне. И при формировании объекта, из переданных в POST значений, будут заполненны лишь определенные поля.
Указывается все очень просто:

protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) throws Exception {
        super.initBinder(request, binder);
        binder.setAllowedFields(new String[] {"title", "content"});
}

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

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

Имхо вот это:

  if ( !StringUtils.isEmpty(value) ) {
  }

гораздо красивее чем то, что я постоянно встречаю:

  if ( value != null && value.length() > 0 ) {
  }

StringUtils это из Jakarta Commons Lang. В Jakarta Commons вообще много чего интересного

Уже раза 3 попадал на ошибку

SEVERE: Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: Unable to read TLD "META-INF/c-1_0.tld" from JAR file "file:/**/jakarta-tomcat-5.5.4/webapps/**/WEB-INF/lib/standard-tags.jar": org.apache.jasper.JasperException: Failed to load or instantiate TagLibraryValidator class: org.apache.taglibs.standard.tlv.JstlCoreTLV

Раз в полгода парюсь с час над этой ошибкой (вот как сейчас было), потом ищу в гугле и выхожу на этот пост в блоге Ryan’на Scraps’а: Frustrating Tomcat 5.5.x Issue Solved (conflicting jars…). Там первое «спасибо» и то мое
В общем ошибка в том что не надо складывать jsp-api.jar servlet-api.jar со своим Web-приложением. И ведь помню, что надо запрещать складывание в WAR этих библиотек, но всеже иногда проскакивают.

Привыкнув к Java, с её идеей о том что все строки всегда хранятся в Unicode, я сильно парюсь в Python.

Гдето чтото не так написал, или не сконвертировал из нужной кодировки в другую нужную, и все, и все полетело Вот тут, в Django, например, чтобы заменить регекспом строку на русском, надо делать так:

#-*- coding: cp1251 -*-

import re
instr = unicode(req.POST['param'], 'utf-8')
pat = re.compile(u'этоубрать', re.U)
instr = re.sub(pat, '_', instr)

а при выплевывании на страницу надо так

messages.append(unicode('Наше сообщение', 'cp1251').encode('utf-8'))

А я все то там, то тут пропускаю, то unicode() то encode() не в том месте, а они все поочереди идут, на выходе непонятно что получается Теперь разобрался вроде.

Когда пишешь resource bundle для Web-приложения часто мешает:

• что для обновления текста на страницах нужно перегружать приложение
• надо конвертить текст написанный по русски в Unicode.

Т.е. дергаем всякие native2ascii или Ant’ом пересобираем и перезапускам приложение.
А в Spring Framework есть замечательный класс ReloadableResourceBundleMessageSource, который решает все эти проблемы.

Читать далее »»

Я неоднократно натыкался на различные обертки для Log4J. Иногда это мотивировалось тем что вдруг мы решим использовать другой логгер или нужно «чтото свое»

В первом случае можно взять Jakarta Commons Logging который говорят и является оберткой поверх логгеров. Хотя по мне так вероятность замены логгера очень близка к нули и это лишь трата времени и забивание головы лишними мыслями «а вдруг?».

Во втором это совсем не причина отказа, т.к. Log4J прекрасно меняется под наши условия, нужно только доки прочитать повнимателней. Можно написать свой appender который куда угодно запишет.
Читать далее »»

При написании Web-приложения на Java под Tomcat у меня, и судя по IRC, у многих других возникала проблема по раскодированию того что нам приходит в GET запросе. Например на сайте может быть формочка поиска, которую принято отправлять GETом. А принимающий сервлет/контроллер получает какуюто чушь. Вроде приложение выдает UTF-8, принимает POST как UTF-8, а в GET чтото не то.

А решение на самом деле простое: прописать в server.xml, для нужного connector’а аттрибут URIEncoding="UTF-8", иначе он думает что там ISO-8859-1 и мы получаем совсем не то.