четверг, 26 июня 2008 г.

Linux 2

Ну вроде разобрался с проблемой зависания. Это определенно не дрова видюхи - без них в консоли все равно висло. Это не перегрев - в винде все ok. Четыре зависших попыток компиляции ядра 2.6.25.9 под ядром 2.6.25.8 показали, что проблема воспроизводима легко. Под 2.6.24 удалось собрать 2.6.25.9. Но собрать под 2.6.25.9 ради теста саму 2.6.25.9 не получилось - висла. Скачал 2.6.26-rc8. Тестовая сборка под этим ядром прошла нормально. Проблемы с протоколом Samba исчезли (интересно, что scp как работала нормально, так и работает). Вроде жизнь наладилась. Всем спасибо за советы.

Итого. 2.6.25.6, 2.6.25.7, 2.6.25.8, 2.6.25.9 - на моей машине (64 бита, AMD) оказались не рабочими.

вторник, 24 июня 2008 г.

Linux

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

Эпизодически, несколько раз в день система фризится напроч. Тоесть мышиный курсор не двигается, музыка не играет и т.д.
Если я в это время залогинен по VNC на зафризенную машину, то в момент этот, я могу максимум что сделать - запустить zsh и все. И то наверное потому, что он в кэш памяти сидит. Изображение прорисовывается по нажатию на кнопку. Например набрал su , но ничего не произошло. Нужно любую кнопку нажать, чтобы увидеть запрос на логин. Странное поведение. В логах ничего подозрительного нет. shutdown -r now не отрабатывает (программа вообще не похоже, что запускается).

Если копирую что-то по smb протоколу, то в файле только первые несколько кил нормальные, а дальше нули идут. Тоесть mp3 музыка играет пару сек и затыкается, если играть smb share'ы. При этом с другого компа доступ к томуже smb ресурсу работает без проблем и глюков. Если копируют mp3'ки мне на шару, то играет все нормально.
Даже не знаю что думать. Куллеры крутятся.. все как обычно. Винда на компе работает нормально, в т.ч. и Crysis. Ядро 2.6.25.(от 6 до 8). Никому ничего не напоминает?

пятница, 20 июня 2008 г.

Документация AspectJ

Если кто-то как и я документацию читает только по-необходимости, то так же как и я может попасть в ловушку при чтении доки на AspectJ. Например глядя на пример:

<include within="javax.*"/>
<include within="org.aspectj.*"/>

может показаться, что аспекты будут применены ко всему, что внутри javax.*, на самом деле это не так ибо, аспекты будут примены только к тем классам, что в javax ни больше ни меньше. Т.е. к классам внутри javax.security это не относится. А если учесть, что непосредственно в javax пакете вообще нет ни одного класса (или есть, но я по памяти не помню), то пример явно идиотский. Короче, должно там быть на самом деле "javax..*"...

вторник, 3 июня 2008 г.

GWT (1.5)

Очень странные ощущения. После возни с AJAX'овыми вещами с помощью JavaScript'а, писать клиентский код на Java просто сказка. Если скомпилировалось - значит заработает. Но компилируется не всегда - к этому надо просто привынуть. Например GWT.create принимает в качестве аргумента Class, но не тут-то было. Например код:
Class c = MyService.class; // или получено из аргумента
MyServiceAsync svc = GWT.create (c);
Прервет компиляцию с сообщением "Only class literals may be used as arguments to GWT.create()".

Подход к package structure, который вроде как strongly recomended, весьма странен с моей точки зрения. Ну сабпакаджи client и server весьма логичны, но вот сабпакадж public - сомнителен (в него предполагается ложить ресурсы как я понял(?)). Более того, client классы не могут зависить от server классов. Т.е. нельзя ложить интерфейс сервиса в package server - его нужно ложить в пакадж client, а в server'е должна лежать только имплементация этого сервиса. Получается по сути таже tier based архитектура, но только наоборот. В классической (ну той к которой я привык), клиентская часть знает о серверной, но не наоборот. А в GWT'ной модели, как раз наоборот получается: серверная часть пользуется классами из клиентской (наследует интефрейсы которые хочет видеть клиент). Собственно это при желании можно обойти сделав отдельный GWT-Module для какого-то отдельно пакаджа с общими классами.. но это ж делать надо и против recomended structure. Впрочем я с первого же дня забил на эту структуру и разложил все по своему - главное понимать, что делаешь и тогда все работает.

Сервисы-сервлеты в Module.gwt.xml не прописываю. Заюзал spring-mvc: прописал в web.xml его диспатчер, а в app context'е прописываю сами сервисы-контроллеры (для spring-mvc они контроллеры, а для gwt они сервлеты, а для клиента они сервисы). Получилось красиво весьма. Пока нравится.

По уровню boilerplate'ности напоминает EJB 2.1.