TECH MIND

XFCE, or KDE4 is not my choice

2009-06-12T12:08:00.000-07:00

After struggling with KDE4 and it's bugs (I wrote about that in my last post, in Russian) I had a dilemma - continue using so loved window manager (I started with KDE1) or find an alternative that would just work, run faster, probably be not so reach for features, but still offer me nice look and feel.

Gnome

On of the most popular window managers ever. I tried it years ago but dislike - there are too many panels, they occupy space on top and bottom of desktop. Trying to combine everything on a single panel takes too much to spend on such a stupid thing.

LXDE

There were many advices to try this window manager out, and at first glance it looks great. But after X session restart the panel started blinking so I had not other choice killing X server. My plan was to find a replacement for KDE, fixing bugs was out of scope. Sorry, next time maybe...

XFCE

Well, looks good but with issues - multimedia buttons do not work, seems not many settings (after KDE of course). But wait, I need a panel, multiple desktops, and nice look and feel. Want it be as cool as possible, but run fast, really fast. Will it?
Now we will pass through configuration steps and check whether result is what we expect. I can say I'm just happy with it :)
XFCE offers configuration tool that allows configure themes, keyboard layout, shortcuts, window and mouse behavior and so on. Let's try to configure them to look and feel like we used to. I skip many steps like looking through a list of window themes and choosing the best one, to save our time.

Autostarting application

This is one of the most important features KDE provides. Many of window managers (including Gnome?) do not save which applications were started in the session and run minimized into tray bar almost all the time. Applications like skype are good targets to be started on session startup, but if they don't itt looks annoying.
We may configure all the applications to start automatically on "Application Autostart" page. For example, skype is what I have on my laptop.

Shortcuts

KDE has many well defined shortcuts that we want to have on XFDE too. Unfortunately on KDE3.5 on Debian I had some multimedia keys, like Mute, unrecognized so extra work with xmodmap was required. In XFCE the issue does not exist so will just assign them to applications/actions.

On "Application Shortcuts" page of "Keyboard" configuration tool I assigned Amarok to be launched on "Music" button press, Opera browser on "WWW", tvtime on "Video":

amarok <-> XF86Music
opera <-> XF86WWW
tvtime <-> XF86Video

Volume and mute control keys presses handled with amixer application. At first I thought popup window with volume % bar would be great but later changed my mind - when control volume/mute from TV tuner remote so do not get bored with popups. Also XFCE mixer plugin handles mixer control events properly and changes icon in system tray accordingly. amixer has many commands and options, so probably you will want to change some:

amixer -q -c 1 sset 'Master',0 10%- <-> XF86AudioLowerVolume
amixer -q -c 1 sset 'Master',0 10%+ <-> XF86AudioRaiseVolume
amixer -q -c 1 sset 'Master',0 toggle <-> XF86AudioMute

Launch application

The applet behavior at first glance looks too simple - there is no autocompletion by executable file name, instead it saves command history and gives a choice from it. Simple, but works. Also, like Gnome, it fails running applications, like Synaptic, that require root privileges. I'm not sure how KDE handles this, even for Gtk applications, but it does. So looking for a command in main menu is the only way if you do not want to play with $DISPLAY and xhost.

Window decoration

Compiz ... uses 3D graphics hardware to create fast compositing desktop effects for window management (thanks to Wikipedia :) ). It creates really cool effects which combined with XFCE give you a replacement to KDE and it's graphic features (btw Compiz can be used with KDE as well).
To configure Compiz use configuration settings manager:

ccsm

Just select effects you like and then launch Compiz daemon:

compiz --replace

Add this command to "Application Autostart" so next time you login Compiz is launched automatically.

I should say that THERE IS life out of KDE, and if you are tired dealing with bugs, lost settings, and slow UI, give XFCE a chance.

More official screenshots here

KDE4 fornever

2009-06-07T04:38:00.001-07:00

Был такой интересный фильм Memento (рекомендую кто не видел), так вот события в фильме разворачиваются с конца. Для тек, кому лень читать, скажу сразу - Run baby, run! Не смейте устанавливать KDE4! Не меняйте 3.5 (или особенно если вы на другом менеджере окон) на это издевательство. Я предупредил. Ниже всего-лишь краткий список проблем, багов, которые были обнаружены после обновления Debian Etch на Squeeze, в течение дня. Совершенствование продукта - вещь необходимая, но путь, выбранный разработчиками, кажется ммм... неправильным что ли. Вспоминаю старые добрые времена KDE 1, 2, 3, когда обновление приносило радость, а не убитые нервные клетки и кучу вопросов вроде "Ну и, что дальше?".

Итак, визуальные дефекты. Надо признать, эта проблема пропала после обновления на последнее ядро (2.6.29.4 с 2.6.23.12), соответственно с пересборкой новых драйверов от nVidia, после чего появилось множество 3D эффектов. Но мальчик то все равно был!

Еще один баг в KDE4 - после установки курсора мыши в KDE Classic, DMZ или любой другой Oxygen, настройка применяется полностью или частично к некоторым окнам, после перезапуска KDE сбрасывается в Oxygen Black. Раздражает - не то слово. В Gnome создается впечатление, что Qt приложения используют курсор установленный в KDE. Называется не хочешь KDE - попробуй в других менеджерах поработать. Ну где же альтернатива (к этому еще вернусь)?

Мультимедиа кнопки в KDE не работают, кроме разве что управления звуком. Что интересно, регулировка звука работает на тот канал, на который настроена. Т.е. звук с TVTime может никак не регулироваться, кроме как из самого TVTime. Темная история, и вероятно, еще не оконченная. При попытке привязать кнопки вроде WWW к запуску приложений имеем баг в Qt.

Была еще масса приколов с опциями - настраивать черный текст на белом фоне в konsole приходилось раз 10 точно. Управление его профайлами - высший пилотаж, когда при 2 профайлов ты видишь 4, и какой же из них активный не понять. Если бы количество нервных клеток было неограничено, их падеж составил бы примерно число Гугл.

Еще хотелось бы покритиковать такие себе "усовершенствования", как главное меню и окно завершения работы в частности. Ну почему столько много пунктов в меню, и всегда один и тот же диалог "Жду XXX секунд..."? В 3.5 меню выглядело более продуманным что ли, здесь же навигация без мыши словно битье головой об стену. Диалог System settings переносит нас в эпоху темного средневековья и инквизиции, в смысле Windows 3.1-like. Найти нужную опцию - непростая задача. Разделение на вкладки главных и расширенных настроек - вершина деградации в разработке пользовательского интерфейса. Desktop folders - вообще непонятно что. Кому в голову могло прийти группировать кучу ярлыков в папки, да еще обведенные этими идиотскими рамочками, портящими обои? Поворот фолдера градусов на 30 вовсе не кажется необходимой опцией. Поскольку рамка имеет границы, то становится непонятно, а зачем же тогда эта всплывающая панель с 3 кнопками?

Для тех, кто все же выбрал путь воина, стоит уделить внимание обновлению того, что могло устареть. Я не про железо, но например, запуск KDE обрывался где-то после ввода пароля в gdm/kdm с появлением окна загрузки, и перед стартом KDE. Что-то вроде could not connect to ksmserver, хотя каждый раз по-разному. Проблема решилась обновлением конфигурации X (/etc/X11/xorg.conf). То же с lirc - irrecord не читал из девайса, пока не пересобрал ядро, с самим lirc.

Итог мучений

С одной стороны, команда разработчиков приклала массу усилий для усовершенствования и развития проекта, за что им, несомненно, спасибо, но такие проблемы в версии 4.2 - это печально... Ищу альтернативу.

Configuring external monitor on Debian laptop

2009-05-30T09:41:00.000-07:00

Here I'll try to describe how external monitor can be used on laptop in mirroring mode.

Hardware details

Laptop supports maximum resolution 1280x800.
Monitor SCALEOVIEW D22W-1 maximum resolution is 1680x1050.

X configuration

Here is /etc/X11/xorg.conf configuration adopted for HP6730b internal
display and external monitor:

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver  "kbd"
 Option  "XkbRules" "xorg"
 Option  "XkbModel" "pc105"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver  "mouse"
EndSection

Section "Device"
 Identifier "Primary Video Device"
        # Intel driver
 Driver  "intel"
 Option  "MergedFB" "true"
        # These modes specify mapping of internal monitor resolution to external
        # monitor resolution, as list of two pairs (X by Y) separated with -
 Option  "MetaModes" "1024x768-1680x1050 1024x768-1280x1024 1024x768-1024x768 1024x768-800x600"
 Option  "MergedDPI" "100 100"
EndSection

Section "Device"
 Identifier "Secondary Video Device"
 Screen  1
EndSection

Section "Monitor"
 Identifier "Laptop Monitor"
EndSection

Section "Monitor"
 Identifier "External Monitor"
EndSection

Section "Screen"
 Identifier "Internal Screen"
 Device  "Primary Video Device"
 Monitor  "Laptop Monitor"
 DefaultDepth 24
 SubSection "Display"
  Depth 24
                # Resolutions supported by laptop display
  Modes "1024x768" "800x600"
 EndSubSection
EndSection

Section "Screen"
 Identifier "External Screen"
 Device  "Secondary Video Device"
 Monitor  "External Monitor"
 DefaultDepth 24
 SubSection "Display"
  Depth 24
                # Resolutions supported by external display
  Modes "1680x1050" "1600x1200" "1280x1024" "1024x768" "800x600"
 EndSubSection
EndSection

Section "ServerLayout"
 Identifier "Default Layout"
 Screen  0 "Internal Screen"
 InputDevice "Generic Keyboard"
EndSection

Please notice that driver set to "intel" - generic driver does not work with VGA output.

Switching resolution

To switch to external monitor with (probably) higher
resolution, create desktop.sh script in /usr/local/bin with following content:

xrandr --output LVDS --mode 1024x768 --set BACKLIGHT_CONTROL legacy --output VGA --mode 1680x1050
# This will completely turn laptop display off, commented out since we control backlight instead
# xrandr --output LVDS --off
# This will set backlight to 10%
xbacklight -set 10

To switch to smaller resolution (that laptop display supports), create
laptop.sh script with content:

xrandr --output LVDS --mode 1024x768 --set BACKLIGHT_CONTROL legacy --output VGA --mode 1024x768
# This will restore backlight to 100%
xbacklight -set 100

I found it much safer/useful to control laptop display backlight,
instead of switching LVDS output off, because it is easier to switch
resolution back, to smaller (something is still visible on display) when
the external monitor is taken away by crazy administrator guy :)

References

Xorg RandR 1.2 Wiki

mergefb - dual monitor setup on a linux laptop

Testing EJB out of application server - Part 3. Spring managed DAO tier

2009-04-19T01:56:00.000-07:00

After a short delay and thinking about giving Spring to manage stateless DAO tier beans, here comes 3-rd part of the article. There were some issues that had to be investigated to make the topic complete. Most of all, there was an open question of controlling Hibernate Session
life cycle, to have OpenSessionInView pattern working.
Let's define what we want to gain with DAO bean management by Spring:
1. Keep DAO beans working with EntityManager to make CRUD operations with entities.
2. Make switch from EJB' @Stateless (and even @Stateful) annotations to Spring' @Service (or have beans configured in XML file).
3. Have bean auto wiring in DAO with Spring IoC, avoiding JNDI lookups and extra configuration in XML file.
4. Ensure transaction and session management is compliant with EJB approach to handle entity beans lazy initialization problem (here I refer to interceptor and callback/template approaches).

Let's examine what changes are to be done to our simple Internet shop application.

DAO tier

Since we do not need to manage DAO beans with EJB but Spring, just change annotations on DAO bean class level:

@Service("purchaseDAO")
public class PurchaseDAOImpl extends AbstractDAO<Purchase> implements PurchaseDAO {
    public PurchaseDAOImpl() {
        super(Purchase.class);
    }
}

Here, we used @Service that is recognized by Spring component scanning functionality we already familiar with. Also, DAO interfaces do not need @Local nor @Remote annotation (so they are removed):

public interface PurchaseDAO extends DAO<Purchase> {
}

There is also a simplification in application context configuration file - DAO beans refering through JNDI to stateful beans managed by EJB have been removed.
Important configuration step is adding <context:annotation-config/> to application context configuration file. This will include support for JPA annotations like @PersistenceContext. To have everything working we need to define bean, with name of persistence unit, which refers to EntityManagerFactory:

<bean id="entityManagerFactory"
      class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
    <property name="targetObject"
              ref="entityManagerBean"/>
    <property name="targetMethod"
              value="getEntityManagerFactory"/>
</bean>

<alias alias="ishopPU"
       name="entityManagerFactory"/>

OpenSessionInView pattern

To be correct, in Spring terms pattern is named OpenEntityManagerInView. There is a significant difference between this new approach and old-style one used by applications, built upon Hibernate ORM, to keep Hibernate Session open for a request processing cycle.
Opening Hibernate Session in filter and binding it to SessionFactory these applications relied on the fact entity beans extracted in DAO tier are kept attached to this session until request has been processed and session is closed, so access to lazily initialized references would not cause an exception.
But the approach, in it's original implementation, does not work for EJB - each transactional method is completed within its own EntityManager instance which holds reference to it's distinct Hibernate Session; opening new session does not make any affect.
Instead, using TransactionSynchronizationManager, we bind EntityManager to EntityManagerFactory so each transactional method executed with the same EntityManager, and as result the same Session, instance used:

@Stateful(name = "openSessionInViewCallback")
@LocalBinding(jndiBinding = "openSessionInViewCallbackLocal")
public class OpenSessionInViewCallbackImpl implements OpenSessionInViewCallback {
@PersistenceContext(type = PersistenceContextType.EXTENDED)
    private EntityManager entityManager;

    @PersistenceUnit(unitName = "ishopPU")
    private EntityManagerFactory entityManagerFactory;

    @Init
    public void invoke(Runnable r) {
        TransactionSynchronizationManager.bindResource(entityManagerFactory, new EntityManagerHolder(entityManager));

        r.run();
    }

    @Remove
    public void remove() {
        TransactionSynchronizationManager.unbindResource(entityManagerFactory);
        EntityManagerFactoryUtils.closeEntityManager(entityManager);
    }
}

In @Init method we bind entity manager, and unbind it on callback method completion with @Remove cleanup. For more information on Spring implementation of the pattern please refer to org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter and org.springframework.orm.jpa.support.OpenEntityManagerInViewInterceptor

Source code

Can be downloaded here.

That's it!

Testing EJB out of application server - Part 2. Integrating Spring

2009-04-05T00:05:00.000-07:00

The aim

In Part 1 I mentioned Spring's transaction management API. I believe this is quite a serious reason to think about integrating Spring framework into EJB application. But not the only one. Spring provides easy way to maintain multiple application configurations with IoC making testing configuration of your application independent of production one. Other features, like JNDI support, integration with JMS, JMX, mail and other services make the framework so popular.
Returning to our internet shop application we have to decide what we want to leave managed by EJB and what we want to put under Spring's control, and look at other options we have.

Data access. We considered JPA as an appropriate way to configure entity and DAO beans that provide basic functionality to access former. DAO stateless beans usually do not depend upon any other application tier, and really seldom use each other; EntityManager gives all an ordinal DAO needs.

Business services. This is really a good place Spring may take care of. Injecting dependencies on other beans (e.g. DAOs), configuration parameters provided within application configuration files, managing transactions is where Spring really strong. Moreover, with Spring testing module we can use these features directly in test classes.

Web services. JSR-181 defines API that is available within stateless beans to define them as providing Web services methods. EJB3 greatly supports this API, and though there is an option to use XFire framework together with Spring, to configure Web services, I see no reason to keep away from standard. Sometimes it is better avoid getting deep into framework hell. Though not always :)

Sample application changes

Domain tier

It is not a surprise that there is nothing to be changed. Entity beans still use JPA for O/R mapping that is controlled by EJB container.

Data access tier

There is one thing that needs to be done to each DAO implementation bean. Since we are going to publish DAO stateless beans in JNDI, so they will be available to Spring, we will use @LocalBinding JBoss annotation to provide bean JNDI name for production environment, as follows:

@Stateless(name = "productDAO")
@LocalBinding(jndiBinding = "productDAOLocal")
public class ProductDAOImpl extends AbstractDAO<Product> implements ProductDAO {
    // methods implementations
}

Every DAO bean is configured in application context configuration file like this one:

<jee:jndi-lookup id="productDAO"
                proxy-interface="org.ishop.dao.ProductDAO"
                jndi-name="productDAOLocal"/>

Unfortunatelly I do not know if there is any way to avoid this, like using automatic scanning.

Service tier

Minor changes should be done to service methods - to switch to Spring transaction API we change @TransactionAttribute to @Transactional and specify other options, if needed. Also dependency injection is now controlled by Spring, based on bean name or type wiring, or on @Autowired annotation:

@Service("productService")
public class ProductServiceImpl implements ProductService {
    @Autowired
    private ProductDAO productDAO;
    @Autowired
    private PurchaseDAO purchaseDAO;

    @Transactional
    public void save(Product product) {
        productDAO.save(product);
    }

    @Transactional(readOnly = true)
    public Product getProduct(Long id) {
        return productDAO.get(id);
    }

    @Transactional
    public Purchase purchase(Long productId, Date paymentDate) {
        // method implementation
    }
}

Please notice that we used @Service that allows us to skip configuring bean in application context configuration file, relying on auto-detection option:

We need to configure transaction management - Spring will use container JTA transaction manager to which it will redirect all transaction processing requests, based on own transaction annotations support and handling:

<bean class="org.springframework.transaction.aspectj.AnnotationTransactionAspect"
     factory-method="aspectOf">
   <property name="transactionManager"
             ref="platformTransactionManager"/>
</bean>

<bean id="platformTransactionManager"
      class="org.springframework.transaction.jta.JtaTransactionManager"/>

Here we configured aspect to support @Transactional annotations. One principal change is made to the build script - Java classes are processed by AspectJ compiler. Another option is use dynamic proxies that will do the same thing. One significant disadvantage of this approach is that to handle calls between business methods of the same service properly they should be made through the proxy.
One more good thing about Spring transaction management API is that service method may throw any exception (checked or unchecked). Instead of annotating exception class with @ApplicationException as EJB spec requires, in @Transactional annotation parameters we may specify which exception(s) should cause transaction rollback and which will lead to commit. Really nice.

Web services

As well as within business tier, Web service need just minor changes in API - replacement of @EJB with @Autowired and adding SpringContextInterceptor interceptor to the list of method call interceptors:

@Interceptors({SpringContextInterceptor.class, OpenSessionInViewInterceptor.class})
public class ProductWebServiceImpl implements ProductWebService {
    @Autowired
    private ProductService productService;
    // methods skipped
}

SpringContextInterceptor is responsible for application context startup when application Web service accessed the first time.

public class SpringContextInterceptor extends SpringBeanAutowiringInterceptor {
    private BeanFactory beanFactory;

    protected BeanFactory getBeanFactory(Object o) {
        if (beanFactory == null) {
            beanFactory = new ClassPathXmlApplicationContext("/applicationContext.xml").getAutowireCapableBeanFactory();
        }
        return beanFactory;
    }

    @PreDestroy
    @PrePassivate
    public void releaseBean(InvocationContext invocationContext) {
        super.releaseBean(invocationContext);
    }

    @PostConstruct
    @PostActivate
    public void autowireBean(InvocationContext invocationContext) {
        super.autowireBean(invocationContext);
    }
}

Changes to unit tests

Spring provides a module to support bean wiring into test classes for both jUnit and TestNG. What we need to change in AbstractPersistenceTest is set up application context and remove lookup() method since we do not rely on bean wiring with EJB:

@ContextConfiguration(locations = {"classpath:/test-applicationContext.xml"})
public abstract class AbstractPersistenceTest extends AbstractTestNGSpringContextTests {
    @BeforeClass(groups = "database")
    public final void setUpDatabase() throws NamingException, IOException {
        Properties props = new Properties();
        props.load(AbstractPersistenceTest.class.getResourceAsStream("/persistence.properties"));
        new InitialContext(props);
    }

    @BeforeClass(dependsOnMethods = "setUpDatabase")
    protected void springTestContextPrepareTestInstance() throws Exception {
        super.springTestContextPrepareTestInstance();
    }
}

Here method springTestContextPrepareTestInstance has been overriden to be called when EJB container has been set up by setUpDatabase().
Testing code does not need serious changes as well as production code does not - use dependency injection with @Autowired instead of looking up for required resource in JNDI.
I strongly believe Spring offers a lot of features which when used in enterprise level applications may reduce coupling of beans and tiers, making daily development and testing easier.

Source code

ishop.ejb-testng-spring.zip

Thanks you!

Getting Maven plugin information

2009-04-01T02:46:00.000-07:00

Recently I have discovered (what a shame I haven't done it much earlier! :) ) that to get information on Maven plugin goals and parameters it is possible to use help plugin (and not dive into plugin descriptor files packaged into JARs):

mvn help:describe -Dplugin=surefire -Dmojo=compile -Ddetail

Here is a plugin self-explanation that does not need extra comments:

$ mvn help:describe -Dplugin=help -Dmojo=describe -Ddetail
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [help:describe] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [help:describe]
[INFO] Mojo: 'help:describe'
help:describe
  Description: Displays a list of the attributes for a Maven Plugin and/or
    goals (aka Mojo - Maven plain Old Java Object).
  Deprecated. No reason given
  Implementation: org.apache.maven.plugins.help.DescribeMojo
  Language: java

  Available parameters:

    artifactId
      The Maven Plugin artifactId to describe.
      Note: Should be used with groupId parameter.
      Deprecated. No reason given

    cmd
      A Maven command like a single goal or a single phase following the Maven
      command line:
      mvn [options] [] []
      Deprecated. No reason given

    detail (Default: false)
      This flag specifies that a detailed (verbose) list of goal (Mojo)
      information should be given.
      Deprecated. No reason given

    goal
      The goal name of a Mojo to describe within the specified Maven Plugin. If
      this parameter is specified, only the corresponding goal (Mojo) will be
      described, rather than the whole Plugin.
      Deprecated. No reason given

    groupId
      The Maven Plugin groupId to describe.
      Note: Should be used with artifactId parameter.
      Deprecated. No reason given

    medium (Default: true)
      This flag specifies that a medium list of goal (Mojo) information should
      be given.
      Deprecated. No reason given

    minimal (Default: false)
      This flag specifies that a minimal list of goal (Mojo) information should
      be given.
      Deprecated. No reason given

    output
      Optional parameter to write the output of this help in a given file,
      instead of writing to the console.
      Note: Could be a relative path.
      Deprecated. No reason given

    plugin
      The Maven Plugin to describe. This must be specified in one of three
      ways:

      1.  plugin-prefix, i.e. 'help'
      2.  groupId:artifactId, i.e. 'org.apache.maven.plugins:maven-help-plugin'
      3.  groupId:artifactId:version, i.e.
        'org.apache.maven.plugins:maven-help-plugin:2.0'
      Deprecated. No reason given

    version
      The Maven Plugin version to describe.
      Note: Should be used with groupId/artifactId parameters.
      Deprecated. No reason given

Testing EJB out of application server - Part 1

2009-03-21T02:22:00.001-07:00

Introduction

Earlier I had a couple of projects that used Hibernate as a persistence framework of choice. Hibernate provides rich API, that is actually a superset of what EJB3 provides, and at the same time it gives an opportunity to test core application modules and services without application server running with the application deployed on it. But using Hibernate for persistence we at the same time stay far from technologies that are standards de jure nowadays. The question is whether it is possible to follow industrial standards and still have things implemented as simple as possible. In this post I'll try to show on example the way how EJB can be used as the primary technology for persistence, bean management and Web services implementation. The most important thing it covers is testing EJBs without deploying developing application onto application server.

EJB spec offers standard way to develop enterprise level application that can be deployed on any application server, that follows the standard, but does not say how we can easily test EJBs. And usually the first what developers decide is to test them remotely on application server. The approach perhaps is the most significant time consumer and requires great experience in EJB development - each redeployment may cost too much in comparison to how much time spent on writing production code that is tested.

Fortunately there is a solution (of course there is always something we can do) - "OpenEJB offers an "embeddable and lightweight EJB 3.0 implementation that can be used as a standalone server or embedded into Tomcat, JUnit, TestNG, Eclipse, IntelliJ, Maven, Ant, and any IDE or application. OpenEJB is included in Apache Geronimo, IBM WebSphere Application Server CE, and Apple's WebObjects." - the title page states.
So, in this post we will focus on using EJB - entity and session beans, and Web services - and testing the application without application server. Since JBoss is a widely used application server, it is evident why it was chosen for development, also evident that there is Hibernate behind the scene. Next time I'm going to focus on integration with Spring framework, so stay tuned..

The price

First of all, you should consider whether functionality Hibernate provides, that is not accessible in EJB, is critical or not for your application. For example, Hibernate Criteria API, perhaps the most significant feature, can be helpful in organizing quick and efficient search on multiple criterions. Without this feature StringBuilder with multiple if/else constructs become our best friends and the worst enemies. Though EntityManager can be cast to HibernateEntityManager to access Hibernate internals, the code will not look so perfect and clear anymore as it was when the Earth had been created. Also EJB needs another approaches to solve familiar problems, like re-implementing OpenSessionInView (Hibernate solution can be found here.

Example application

Domain tier

Let's focus on a simple Internet shop application that sells products and tracks each product purchase in database. For mapping entities to database tables JPA annotations are used. Sure, Hibernate specific annotations, like @Index, still can be used, especially if you need to generate database schema script. Let's just keep things simpler.

@Entity
@Table(name = "product")
@SequenceGenerator(name = "product_generator", sequenceName = "product_seq")
public class Product {
    @Id
    @Column(name = "id")
    @GeneratedValue(generator = "product_generator")
    private Long id;

    @Column(name = "code", nullable = false)
    private String code;

    @OneToMany(mappedBy = "product", fetch = FetchType.LAZY)
    private Set<Purchase> purchases = new HashSet<Purchase>();

    // ...
}

@Entity
@Table(name = "purchase")
@SequenceGenerator(name = "purchase_generator", sequenceName = "purchase_seq")
public class Purchase {
    @Id
    @Column(name = "id")
    @GeneratedValue(generator = "purchase_generator")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id", nullable = false)
    private Product product;

    @Column(name = "payment_date", nullable = false)
    private Date paymentDate;

    // ...
}

No magic here - things look really familiar.

Data access tier

DAO beans are simple as well, and rely on EJB3 interfaces:

public interface DAO<T> {
    void save(T obj);

    T get(Long id);
}

@Local
public interface ProductDAO extends DAO<Product> {
}

public abstract class AbstractDAO<T> implements DAO<T> {
    @PersistenceContext(unitName = "ishopPU")
    private EntityManager entityManager;

    public void save(T obj) {
        entityManager.persist(obj);
    }

    // other methods
}

@Stateless(name = "productDAO")
public class ProductDAOImpl extends AbstractDAO<Product> implements ProductDAO {
    // ProductDAO interface methods
}

@Local marks business interface for DAO and @Stateless controls DAO implementation beans management by EJB container. Also AbstractDAO takes reference to the entity manager for the ishopPU persistence unit, configured in persistence.xml configuration file. Persistence unit name is required when we have more than one unit listed in this file.

Service tier

Stateless session beans that provide business methods to clients, like Web services and UI, may look as follows:

@Local
public interface ProductService {
    // business methods
}

@TransactionManagement
@Stateless(name = "productService", mappedName = "productService")
public class ProductServiceImpl implements ProductService {
    @EJB
    private ProductDAO productDAO;

    @TransactionAttribute
    public void save(Product product) {
        productDAO.save(product);
    }

    @TransactionAttribute
    public Product getProduct(Long id) {
        return productDAO.get(id);
    }

    @TransactionAttribute
    public Purchase purchase(Long productId, Date paymentDate) throws BusinessException {
        // implementation
    }
}

Business method purchase() throws BusinessException that is annotated with @ApplicationException on class level. I have to say that Spring transaction management API is much cleaner and allows to control more aspects, like isolation level, read-only option and commit/rollback behavior depending on thrown exception type, on method and not on exception class level. That's one more reason you may consider it's use in the project.

Web service

Web service looks the same way as business service except implementation class is annotated with JBoss specific annotation to specify concrete URL and JNDI context name we want to bind the service to:

@WebService(name = "ishop",
        targetNamespace = "http://ishop.org",
        serviceName = "productWebService")
@WebContext(contextRoot = "/ishop-ws", urlPattern = "/productWebService")
@Remote(ProductWebService.class)
@RemoteBinding(jndiBinding = "productWebServiceRemote")
@Stateless
public class ProductWebServiceImpl implements ProductWebService {
    @WebMethod
    public ProductBean getProduct(@WebParam(name = "id") long id) {
        // implementation
    }
}

Production code configuration

Persistence unit configuration is also plain, but you should notice that ishopPU unit is configured to be used with Hibernate as persistence provider (org.hibernate.ejb.HibernatePersistence) and properties listed in properties XML element go directly to the provider. The most important is that we specify dialect to use - Oracle (org.hibernate.dialect.OracleDialect) and other options like log SQL statements executed (set to true) and automatic database schema generation (set to none).

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
             version="1.0">

    <persistence-unit name="ishopPU" transaction-type="JTA">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>

        <!-- Data source name -->
        <jta-data-source>java:/ishopDS</jta-data-source>

        <!-- Persistent classes -->
        <class>org.ishop.domain.Product</class>
        <class>org.ishop.domain.Purchase</class>

        <properties>
            <!-- Hibernate specific properties -->
            <property name="hibernate.dialect" value="org.hibernate.dialect.OracleDialect"/>
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.hbm2ddl.auto" value="none"/>
        </properties>
    </persistence-unit>
</persistence>

Properties specified for Hibernate will be used in production. For testing we will use HSQLDB as we do not need to access any pre-existing data, and will generate it for each test. Below is discussed how to change these properties (at least database dialect), for testing environment.

Testing code configuration

Let's consider what we do to test all the stuff out of application server. Assume we want to test DAO, business logic and call Web service remotely to check that application was deployed successfully in production environment, and works well.

At first, to keep session beans JNDI names consistent, we configure OpenEJB descriptor file openejb-jar.xml:

<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
    <properties>
        openejb.deploymentId.format = {ejbName}
        openejb.jndiname.format = {deploymentId}{interfaceType.annotationName}
    </properties>
</openejb-jar>

so each session bean JNDI name consists of two components - bean name and interface type name (either Local or Remote).

JNDI Configuration file for testing environment - jndi.properties - initializes JNDI context factory for OpenEJB:
```
java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
```

The last what we do is >re-configure persistence context, in persistence.xml file to switch to testing data source:

java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory

# Data source configuration
ishopPU=new://Resource?type=DataSource
ishopPU.JdbcDriver=org.hsqldb.jdbcDriver
ishopPU.JdbcUrl=jdbc:hsqldb:localdb/localdb

# These properties override specified in persistence.xml
ishopPU.hibernate.dialect=org.hibernate.dialect.HSQLDialect
ishopPU.hibernate.hbm2ddl.auto=create-drop

Now in unit tests OpenEJB uses HSQLDB for persistence, with correct dialect and other Hibernate properties.
The syntax for property is following:

<PERSISTENCE UNIT NAME>.<HIBERNATE PROPERTY NAME>=<PROPERTY VALUE>

Writing testing code

I won't be explaining here why I chose TestNG - you may easily switch to jUnit if you want to. Let's create abstract base class for tests that need access to database, and add setUpDatabase() method that initializes local database before class test methods run, loading configuration from persistence.properties file. Since all session beans are published by the container in JNDI, to access them we create an utility method lookup() that returns any bean from JNDI contaxt, by bean JNDI name:

public abstract class AbstractPersistenceTest {
    private Context context;

    @BeforeClass(groups = "database")
    public final void setUpDatabase() throws NamingException, IOException {
        Properties props = new Properties();
        props.load(AbstractPersistenceTest.class.getResourceAsStream("/persistence.properties"));
        context = new InitialContext(props);
    }

    @SuppressWarnings("unchecked")
    protected final <T> T lookup(String name) throws NamingException {
        return (T) context.lookup(name);
    }
}

Below is a simple business service test class:

public class ProductServiceTest extends AbstractPersistenceTest {
    private ProductService productService;

    private Product product;

    @BeforeClass(groups = "database")
    public void setUpService() throws NamingException {
        productService = lookup("productServiceLocal");
    }

    @BeforeMethod(groups = "database")
    public void createProduct() {
        product = new Product();
        product.setCode("ABCDEF");
    }

    @Test(groups = "database")
    public void testSave() {
        productService.save(product);

        Assert.assertNotNull(product.getId());
    }

    // other tests
}

Before class test methods run, setUpService() and createProduct() methods are invoked to get reference to ProductService bean and create test Product.

Lazy initialization problem

The problem is caused by dynamic proxies Hibernate generates instead of loading business entities or collections from database. Usually that is FetchType.LAZY specified for fetch attribute in @OneToMany and similar mapping configuration annotations. Solution existing for enterprise applications using Hibernate for persistence is opening Hibernate Session for HTTP request and keeping it open till request processing is complete. Entities loaded in any transaction stay attached to HTTP session so Web page may access lazily loaded collections and entities without LazyInitializationException being thrown.
Assume that in EJB we have no access to Hibernate internals, but there are choices how we may solve the problem.

Access lazily loaded objects in transaction.

For this purpose we access all our business methods in a single transaction. For example, annotate Web service bean with @TransactionManagement (that is actually done by EJB container by default) configured to use container transaction management (TransactionManagementType.CONTAINER):
```
@TransactionManagement
// other annotations suppresses
public class ProductWebServiceImpl implements ProductWebService {
    // implementation
}
```
This will grant that Web service and business methods are executed in the same transaction. Not the best solution, expecially because it damages business methods transaction boundaries, causing unexpected errors and probably missing results. It may not work for business methods with propagation level REQUIRES_NEW, and certainly will cause problems with NEVER.

Template method.

The idea is to wrap multiple business methods and execute them in a single transaction boundary. Seems there is no difference with the previous approach, but we can use EXTENDED persistence context mode when persistent entities kept attached to stateful bean till the moment the bean is removed from context:

@Local
interface OpenSessionInViewCallback {
    void invoke(Runnable r);

    void remove();
}

@Stateful(name = "openSessionInViewCallback")
public class OpenSessionInViewCallbackImpl implements OpenSessionInViewCallback {
    @PersistenceContext(type = PersistenceContextType.EXTENDED)
    private EntityManager entityManager;

    @Init
    public void invoke(Runnable r) {
        r.run();
    }

    @Remove
    public void remove() {
    }
}

Template class gets reference to the stateful bean from JNDI context and removes bean from context when callback method is executed:

public final class OpenSessionInViewTemplate {
    public static void invoke(Runnable r) {
        OpenSessionInViewCallback callback = null;
        try {
            // make lookup for callback bean
            Context context = new InitialContext();
            callback = (OpenSessionInViewCallback) context.lookup("openSessionInViewCallbackLocal");

            // invoke runnable
            callback.invoke(r);
        } catch (NamingException e) {
            throw new RuntimeException(e);
        } finally {
            if (callback != null) {
                // remove bean
                callback.remove();
            }
        }
    }
}

Any business methods calls can be done in run() method of Runnable without
LazyInitializationException thrown and affecting business methods transactions boundaries. Unit tests may need to use template method approach.

Interceptor.

The solution is similar to the previous one but the calling code will look much simple now:

@Remote(ProductWebService.class)
@Stateless(name = "productWebService")
@TransactionManagement(TransactionManagementType.BEAN)
@Interceptors(OpenSessionInViewInterceptor.class)
public class ProductWebServiceImpl implements ProductWebService {
    @EJB
    private ProductService productService;

    @WebMethod
    public ProductBean getProduct(@WebParam(name = "id") long id) {
        ProductBean bean = null;

        Product product = productService.getProduct(id);
        if (product != null) {
            bean = new ProductBean();
            bean.setId(product.getId());
            bean.setCode(product.getCode());
            Date lastPaid = null;
            for (Purchase purchase : product.getPurchases()) {
                if (lastPaid == null || lastPaid.after(purchase.getPaymentDate())) {
                    lastPaid = purchase.getPaymentDate();
                }
            }
            bean.setLastPaid(lastPaid);
        }
        return bean;
    }
}

In this example, thankfully to OpenSessionInViewInterceptor interceptor, invocation of getPurchases() will not cause error, at the same time any transaction boundary is not affected as well.

Deploying application and running tests

After application has been built with Maven:

mvn package

and everything was fine (pray first), you need to copy ishop-ear/src/main/resources/ishop-ds.xml to JBoss server/<CONFIGURATION>/deploy directory and configure according to your environment. Ensure that database driver JAR file is in JBoss application server class path. Execute schema.sql and sample.sql scripts to populate database with required tables and add sample data (databases other than Oracle may need to have them tuned). Copy ishop-ear/target/ishop-ear-1.0.ear to the same application server deployment directory. Start JBoss for that configuration:

$JBOSS_HOME/bin/run.sh -c <CONFIGURATION>

To check Web services change to ishop-wsclient/target and launch application like follows:

java -jar ishop-wsclient-1.0.jar 1

where 1 is the first product ID in production database. To have Web service client working ensure that application server has been started and available on port 8080 on local host (default settings).

Conclusion

Though following enterprise standards sometimes is a difficult decision and has its consequences, in many cases switching to EJB may increase application portability making, in the future, migration to another platform more transparent, reducing costs spent on application development and further support. At the same time, it is not so hard, as we may imagine at first, to develop and especially test enterprise application, based on EJB, out of application server. And OpenEJB helps with this.

Source code

ishop.ejb-testng.zip

Thank you.

Setting select into/bulkcopy option in Sybase

2009-03-20T12:47:00.000-07:00

Oh, how often Sybase makes me like mad. Why should I turn options on or off just to make an ordinal action like adding column which can not be NULL? Here is a snippet that helps to deal with those 'select into/bulkcopy option is disabled' errors. Not sure somebody does not know it yet, Rather I want to be sure I will not forget it before we migrate to Oracle.

USE master;
EXEC sp_dboption mydb,'select into/bulkcopy/pllsort',true;
USE mydb;
-- ALTER TABLE goes here
USE master;
EXEC sp_dboption mydb,'select into/bulkcopy/pllsort',false;

mydb is a database name, should be properly selected.

Installing Debian 5 (Lenny) on HP6730B laptop (model GB988EA#ECB)

2009-03-20T09:56:00.000-07:00

Audio support

Following information published on Wiki and Issue page, I was able to configure audio module so it is recognized properly and sound is available both on speakers and microphone audio output. In short, following was done:

In file /etc/modprobe.d/options added one more
line:
options snd-hda-intel model=mobile
In file /etc/modprobe.d/als-base added the same (not sure whether it was necessary):
options snd-hda-intel model=mobile

Then just reboot.

Keyboard

To configure multimedia buttons need to create /etc/X11/Xmodmap file and add following lines:

keycode 129 = XF86Music
keycode 162 = XF86Video
keycode 160 = XF86AudioMute
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 178 = XF86WWW

This file is read by xmodmap utility, launched by display manager on X session startup. Key codes were taken from xev command output, and mapping from /usr/include/X11/XF86keysym.h and
/usr/include/X11/keysymdef.h files of the linux kernel source tree. The laptop supports only audio control keys (which are software keys), e.g. mute and volume +/- control. Other keys I keep because my external keyboard Logitech UltraX supports them. I wonder why these are still not set by the Debian installer automatically (are codes are non-standard?). Binding to KDE events can be changed in KDE
Control Center->Regional settings->Keyboard layout.
For example, for Opera application I set combination XF86WWW.

Touchpad

Works well.

Wi-FI

Reported it works, but I have not checked it out. Recognized as Hewlett-Packard Wireless (Bluetooth + WLAN) Interface.

Camera

Upgrade Linux kernel to 2.6.28, which has support for HP WebCam. Cheese, XawTV and Skype work well.

Power management

While compiling kernel, enabled power management and ACPI extensions, so when either the lid is closed or on Fn+F3, laptop goes to suspend mode. Here are some issues I watch from time to time:

laptop sometimes does not switch into suspend mode. Still have no idea what is wrong with it (some kind of resources are busy?).
On wake up fan starts turning with 100% speed. This seems to be a bug. This happens every 4th time or so, suspending and wakening up helps, but is really annoying.

USB

Flash drives, keyboards and mices work well.

Display

Works well, backlight can be configured with xrandr. My following entry will touch this, describing external monitors attachment.

Video

Recognized Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller, by default X configuration uses some default driver. To change to Intel one, add line in /etc/X11/xorg.conf:

Section "Device"
    Identifier      "Primary Video Device"
    Driver          "intel"
# options may go here ...
EndSection

Fingerprint

Does not work due to absence of appropriate driver. Maybe there is, I do not care so much about it.

DVD

Works just fine. Recognized as CDDVDW TS-L633L.

Card reader

Recognized as HP Flash Media Reader. Works - tested on SD card.

Network adapter

Installed adapter is recognized as NetLink BCM5787M Gigabit Ethernet PCI Express, and works well.

Firewire

Recognized as Agere Systems FW323, have no idea whether it works or not.

Laptop user opinion

Pros

Price. I beleive it corresponds to performance, which is quite enough to develop enterprise applications for Java platform. It simultaneously runs Web browser (Opera), mail client (Icedove), IDE (IntelliJ IDEA) and JBoss on deployment, and some other staff, with sufficient performance.
Key board layout is really good one, though that's my first notebook. Also Fn key is not the most left one, and that's great.
Not to heavy to carry in business trips.

Cons

Absance of Caps Lock indicator. Well, there could not be one because there is no such key, but it would be great to have some indicator I could watch keyboard layout indicator state (except English I have Russian one). Sounds really funny, but that's what I am accustomed to.
Keys next to Power button seem to be hardware ones and are not recognized by xev, what makes them useless.
There is no DVI output, but VGA and HDMI instead. Is DVI dead yet?

Thanks for reading.

Configure site plugin for Maven multi-project

2009-01-01T23:18:00.000-08:00

Sometimes we want to configure look-and-feel for the product site generated by Maven. There is no need to describe how to do that for a single project - Maven documentation quite clearly describes it on Creating Content page. On the other hand there is no need to repeat the same configuration for each sub-module's POM in multi-module project. Here is a short description what steps need to be performed to reduce code/markup duplication to add custom logo and make changes to CSS for every site to be generated, both root module one's and sub-modules'.

The first step is creating src/site/resources directory that will contain our images and CSS files, in the root module. As it is described on the site plugin documentation page, we need to configure src/site/site.xml descriptor for our sites:

<?xml version="1.0" encoding="UTF-8"?>
<project name="My project">
    <bannerLeft>
        <name>myproject</name>
        <src>images/logo.jpg</src>
        <href>http://en.wikipedia.org/wiki/My_Science_Project</href>
    </bannerLeft>
    <skin>
        <groupId>org.apache.maven.skins</groupId>
        <artifactId>maven-classic-skin</artifactId>
        <version>1.0</version>
    </skin>
    <body>
        <links>
            <item name="${project.name}" href="${project.url}"/>
        </links>

        <menu ref="parent"/>
        <menu ref="modules"/>
        <menu ref="reports"/>
        <menu name="Links">
            <item name="Wiki page" href="http://en.wikipedia.org/wiki/My_Science_Project"/>
        </menu>
    </body>
</project>

Here we declared that index page will have banner on top left and click on it will lead to My Science Project movie Wiki page (as example). We use Maven classic skin (some styling we will change later). In <body> element we configure default parent, modules and reports menu items, and provide one more link to Wiki page as part of Links menu. Nothing special yet.

Following plugin documentation, create two sub-directories - css and images. We use the first one to keep all our CSS files - for that we create site.css file that will contain content similar to
```
h2 {
    background-color: #5587B7;
}
```
By default site.css generated (and used) by site plugin is empty, and providing this we change styling for HTML element specified in maven-theme.css.
Next, we copy our site logo image logo.jpg into images sub-directory.

The last but not the least is configuring our POMs. It is predictable that all changes should be done to the root POM - that's the aim of our configuration and the post itself:) Main difference between parent and children POMs is difference in path to site descriptor file and resources. So we need to divide configuration used by the root and child POMs. Here how we do this:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-site-plugin</artifactId>
            <inherited>false</inherited>
            <configuration>
                <siteDirectory>${project.basedir}/src/site</siteDirectory>
            </configuration>
        </plugin>
    </plugins>

    <pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-site-plugin</artifactId>
                <configuration>
                    <siteDirectory>${project.parent.basedir}/src/site</siteDirectory>
                </configuration>
            </plugin>
        </plugins>
    </pluginManagement>
</build>

Plugin configuration in pligins element overrides configuration of the one in pluginManagement, it also has inherited attribute set to false so the changes are not propagated to child modules and their POMs. So, configuration of in pluginManagement element specifies correct path for sub-modules - they access site resources through their parent.

Sample multi project can be found here: myproject.zip
That's it!