Richfaces / Trinidad совсемстно с Facelets

Проапргрейдил существующий проект с Java 1.4 до Java 1.5, JSF 1.1 до JSF 1.2, реализацию JSF с Myfaces на Sun RI... и решил использовать в проекте какой-нибудь фреймворк предоставляющий AJAX для JSF. Первым попробовал Richfaces. Но оно как-то нестабильно заработало - то работает, то нет. Потратил два дня пытаясь понять почему, но безрезультатно. Затем попробовал Trinidad.. и с тем же успехом. Фреймворк работал нестабильно. Например, я открывал JSF страницу, и если кликал на AJAX'овую кнопку сразу после загрузки страницы, то все было нормально, запрос шел и обрабатывался, а если спустя пару секунд кликал, то запрос не обрабатывался и нужная часть страницы не обновлялась. Через какое-то время обратил внимание на странное и уже привычное сообщение в логах "INFO: Facelet[/page/blah.xhtml] was modified @ 14:23:24 AM, flushing component applied...". Оказалось, что это и есть причина проблемы. Время в виртуальной машине было на три часа меньше времени на компе на котором я собирал WAR файлы. Соответственно время создания файлов выглядила для websphere'ы на три часа из будущего. И похоже, что странный алгоритм Facelets обнаружения изменений в файлах начал сбоить по этой причине и перечитывать файл сбрасывая при этом дерево компонент! Решил проблему, установив facelets.REFRESH_PERIOD контекстный параметр в web.xml. Теперь оба фреймворка работают нормально. Осталось только определится какой я хочу..

Простое DSL на Scala

Недавно я начал использовать Scala для одного из моих домашних хобби проектов. Ранее я слышал, что Scala позволяет писать код таким образом, что он выглядит как DSL встроенный в саму Scala'у. Решил попробовать использовать эту фичу. Мне было необходимо придумать красивое API для шедулинга сообщений актерам (actors). Вот что из этого получилось:

final class TimeSpec[T] (number : Long, action : Long => T) {
    def nanoseconds  = action (number)
    def microseconds = action (number * 1000L)
    def miliseconds  = action (number * 1000L * 1000L)
    def seconds      = action (number * 1000L * 1000L * 1000L)
    def minutes      = action (number * 1000L * 1000L * 1000L * 60L)
    def hours        = action (number * 1000L * 1000L * 1000L * 60L * 60L)
    def days         = action (number * 1000L * 1000L * 1000L * 60L * 60L * 24L)
}

final class Trigger (actor : MyActor, payload : Any) {
    def in (number : Long)    = new TimeSpec[Unit] (number, scheduleIn)
    def every (number : Long) = new TimeSpec[Unit] (number, scheduleEvery)

    private def scheduleIn (nanos : Long)    = Scheduler.inNano (actor, payload, nanos)
    private def scheduleEvery (nanos : Long) = Scheduler.everyNano (actor, payload, nanos)
}

final class ActorSchedule (actor : MyActor) {
    def payload (payload : Any) = new Trigger (actor, payload)
}

trait MyActor ..... {
    protected val schedule = new ActorSchedule (this)
    ....
}

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

object TestActor extends MyActor {
    schedule payload `Hi in 10 nanoseconds

    schedule payload `HowAreYou every 5 seconds

    schedule payload `Bye in 5 days

    def act () = {
        case `Hi => println ("Hello!")
        case `HowAreYou => println ("I am fine")
        case `Bye => println ("Bye-bye")
    }
}

Идея в том, что schedule - это объект класса ActorSchedule. Этот класс предоставляет один метод payload имеющий один аргумент (собственно то, что будет послано актеру). В действительности "schedule payload `Hi" это вызов "schedule.payload(`Hi)". Этот вызов создаст объект класса Trigger. У класса Trigger есть два публичных метода in(Long) и every(Long). Так как эти методы не могут ничего полезного сделать до тех пор пока не будет известна единица измерения времени, то эти методы создают объекты TimeSpec передавая им в качестве параметра собственный метод, который будет вызван с количеством наносекнуд одним из методов класса TimeSpec.

Как мне кажется получился достаточно простой и удобный API без особых усилий.

CeBootLin - автозагрузка Linux/Android из WinCE на Loox 5XX (560/550)

Написал "bootloader" для загрузки Linux/Android из WinCE автоматически при включении КПК. Это не настоящий bootloader, так как он не имеет ничего общего с загрузочными секторами, это просто WinCE приложение, которое начинает свою работу как можно раньше, чтобы загрузить Linux. Я сделал это именно так, а не иначе, из-за того, что не хотел убить свою КПК изменением бут секторов или иметь сложный механизм перепрошивок, обновлений и т.д. Автозагрузка из WinCE мне показалась досточно неплохим решением, имеющим разве что 3-4 секундный проиграш, если сравнивать с нормальным bootloader'ом, который еще помучиться реализовать надо. Также, такая рализация позволяет достаточно легко пропустить загрузку Linux и продолжить загрузку WM5 или WM6.. Код основан на утилите Haret (спасибо им), но я удалил ненужные мне части. Так как загрузчик использует аппаратные регистры для работы с клавиатурой и подсветкой (GPIO/CPLD) Fujitsu Siemens Loox N560/C550, то без изменений кода данный загрузчик не заработает на другой модели КПК...
Когда КПК включается и начинается загрузка WinCE, то ядро WinCE читает список приложений из HKEY_LOCAL_MACHINE\init и запускает их. Таким способом загружается CeBootLin. CeBootLin начинает мигать подсветкой клавиатуры и ждет одну секунду. В то время, пока клавиатура подмигивает, пользователь может нажать и отпустить какую-нибудь кнопку КПК - это сигнал для CeBootLin не продолжать загрузку Linux. Если никакие кнопки нажаты не были, то CeBootLin попытается открыть \CeBootLin\default.txt и будет использовать его в качестве скрипта Haret для загрузки Linux'а.

Итого, чтобы поставить и настроить CeBootLin, надо проделать такие шаги:
1. Скачать CeBootLin.
2. Распаковать содержимое архива в корень основной памяти КПК. CeBootLin.exe должен быть доступен по пути \CeBootLin\CeBootLin.exe.
3. Поместить default.txt в каталог \CeBootLin. Файл default txt может например выглядеть так (для загрузки Andorid'а, например):

set MTYPE 1454
set KERNEL "\CeBootLin\zImage"
set CMDLINE "root=179:3 mem=62M rootdelay=3 boot_delay=0 init=/init console=tty0 fbcon=rotate:0 androidboot.console=tty0 android.checkjni=1"
set RAMADDR 0xA0200000
bootlinux

4. Поместить zImage в каталог \CeBootLin\.

5. Добавить в HKEY_LOCAL_MACHINE\init значение для Launch82 ="CeBootLin.exe" и Depend82 = 14 00.


6. Добавить в HKEY_LOCAL_MACHINE\Loader\SystemPath путь \CeBootLin\

7. Подождать 5 минут или типа того (WinCE нужно время, прежде чем она сохранит обновление в registry).
8. Перезагрузить КПК

Если возникнут какие-то проблемы, то первым делом стоит проверить, а грузит ли CeBootLin.exe вообще ядро... для этого достаточно просто его запустить.

В дальнейшем при желании можно сделать нормальный cab с setup'ом внутри, который, например, будет ставить андройд..

Здесь находятся исходные коды CeBootLinux. CeBootLinux лицензирован под GNU GPL.

Фотографии Android и Linux на Fujitsu-Siemens Loox N560

Сегодня судьба WM5 - загрузить Linux


Haret.. все что нужно - нажать Run


Android на Loox N560


Установка Debian'а на Loox N560


Установка Debian'а на Loox N560

Тестирование памяти на Loox N560/C550

Недавно набросал "утилиту" для тестирования памяти на Fujitsu-Siemens Loox N560/C550. Нужна она тем, кто перепаевает память (с 64М на 128М) и хочет проверить ее работоспособность "на месте" без переустановки WM5. Итак, для того, чтобы протестировать память КПК:
1. Качаем LooxMem128-v0.zip (чтобы тестировать 128Мб памяти) или LooxMem64-v0.zip (чтобы тестировать 64Мб памяти).
2. Заливаем распакованный архив на SD карточку.
3. Карточку вставляем в Loox и перегружаем КПК.
4. Не давая КПК заснуть, запускаем haret.exe из архива, что распаковывали на SD карточку.
5. После запуска haret.exe нужно нажать на Run.
6. Загрузится linux и появится предупреждение.
7. Читаем предупреждение и либо нажимаем на RESET (на попе у КПК) либо нажимаем enter..
ВНИМАНИЕ: Накачественная память при тестировании может сгореть (собственно "утилита" для этого и нужна, чтобы выявлять такую память). Ни я, ни авторы memtester ни кто иной кроме вас никакой ответственности за это нести не будет. Вы тестируете память на свой страх и риск!!

Замечание: При тестировании необходимо раз в 3-5 минут нажимать какую-нибудь кнопку КПК, чтобы КПК не заснула...
(Для портирования "утилиты" на другую платформу достаточно заменить ядро zImage и поправить default.txt.)

Ядро linux для Loox N560/C550 с рабочим CPLD и светодиодами

Добавил поддержку CPLD и светодиодов. Для CPLD был заюзан драйвер htc-gpio с перечислением адресов регистров CPLD на Fujitsu-Siemens Loox 5XX (N560/C550). Теперь CPLD доступен для других драйверов.

Примечательно, как в Linux'е реализована работа с CPLD. По сути, CPLD это чип, содержащий очень простую логику (за счет чего он очень быстр по сравнению с CPU), имеющий входные и выходные "ножки" (pins). Входные и выходные ножки - регистры - проецируются на определенную область памяти CPU. С логической точки зрения работа с CPLD заключается в переключении битов в регистрах CPLD в 0 или 1 (можно еще и читать оттуда, но я об этом тут не буду рассказывать..). Таким же образом выглядит работа с GPIO - общим вводом/выводом CPU: биты регистров CPU таким же образом принимают значение 0 или 1. В ядре Linux уже имеется драйвер GPIO, предоставляющий функции для работы с GPIO разработчикам платформенных драйверов. Также драйвер GPIO имеет механизм расширения, позволяющий другим драйверам/модулям проецировать заданные интервалы портов GPIO таким образом, что при обращении к такому порту произойдет вызов указанных при проецировании функций. Этот механизм используется CPLD драйвером htc-egpio для проецирования CPLD регистров на GPIO порты. Таким образом работа с CPLD идет через обыкновенные методы типа gpio_set_value.
На основе работающиго CPLD драйвера для Loox N560/C550 реализовал драйвер управления светодиодами КПК. Драйвер экспортирует методы и константы которые другие драйвера (wifi, gps, bluetooth, pm, ...) должны использовать для управления светодиодами. Также драйвер позволяет контролировать светодиоды из userspace пространства путем манипуляций с файлами sysfs.

Ниже перечисленны файлы и значения которые могут находиться:
/sys/devices/platform/loox5xx-leds.1/keyboard: on, off, any
- подсветка клавиатуры

/sys/devices/platform/loox5xx-leds.1/left_green: on, off, any
- зеленый светодиод с левой стороны. WM5 использует для индикации активности WiFi

/sys/devices/platform/loox5xx-leds.1/left_blue: on, off, any
- голубой светодиод с левой стороны. WM5 использует для индикации активности Bluetooth

/sys/devices/platform/loox5xx-leds.1/left_orange: on, off, any
- оранжевый светодиод с левой стороны. WM5 использует для индикации активности GPS на Loox N560

/sys/devices/platform/loox5xx-leds.1/right_green: on, off, any
- зеленый светодиод на правой стороне КПК. WM5 использует как светодиод доступный приложениям (нотификации и т.д.)

/sys/devices/platform/loox5xx-leds.1/right_orange: on, off, blink, any
- оранжевый светодиод с правой стороны КПК. WM5 использует для индикации процесса зарядки

Где:
on - светодиод включен независимо от желаний ядра,
off - светодиод выключен независимо от желаний ядра,
blink - светодиод мигает независимо от желаний ядра,
any - светодиод контролируется ядром.

Например, если установить right_orange в состояние on, то светодиод зарядки будет гореть независимо от того, заряжается КПК или нет. Это будет продолжаться до тех пор, пока в файл right_orange не будет записано значение any. После чего, первое же событие (установка КПК в крэдл и т.д.) переключит светодиод в соответствующее состояние. Sysfs интерфейс для светодиодов позволяет использовать светодиоды из программ для нотификации о событиях (пришла почта, кончается заряд и т.д.) с помощью всех доступных на устройстве светодиодов - насколько хватит фантазии. Например следующий shell код мигает подсветкой клавиатуры:

while true;
  do echo on > /sys/devices/platform/loox5xx-leds.1/keyboard;
  sleep 0.1;
  echo off > /sys/devices/platform/loox5xx-leds.1/keyboard;
  sleep 0.1;
  # Condition for break...
done
echo any > /sys/devices/platform/loox5xx-leds.1/keyboard;

Актуальный патч на cupcake ядро андройда качать здесь.

Полезные команды для межплатформенной работы

Несмотря на то, что debian/emdebian уже содержат громадное количество пакетов под armel, иногда нужно собрать или пересобрать что-то из исходников.

Сборка пакетов в emdebian происходит например так:

emsource --arch armel -b memtester

Установка собранного пакета НЕ на целевом устройстве, а на хостовом, выполняется например вот так:

dpkg-cross -a armel -i zlib1g-dev_1.2.3.3.dfsg-13em1_armel.deb

При этом команда dpkg -l | grep zlib1g выдаст:

ii  zlib1g-dev-armel-cross                1:1.2.3.3.dfsg-13em1

(dpkg-cross автоматически переназвала установленный пакет и разместила его содержимое в /usr/arm-linux-gnueabi)

Чтобы пользоваться командой emsource без привелегий root'а, надо настроить ~/.apt-cross/emsource например вот так:

workingdir: /home/akshaal/.apt-cross-working-dir

Сборка пакета под armel из исходников, которые уже развернуты и имеют каталог debian производится командой:

dpkg-buildpackage -aarmel