Being part of something special makes you special!

Why Apache iBATIS is still a killer library

2010-04-09T17:38:00.003+02:00

Follow below words written by Clinton Begin, the creator of Apache iBATIS:

"This is what has killed J2EE vs. the alternatives. Look at the history:

CMP - Spec. Dead, along with all implementations.

EJB - Spec. Dead. Spring killed it -- not a spec.

JDO - Spec. Dead, along with all implementations.

JSF - DOA. Bad idea to begin with, and has failed to unify client side Java. Struts, GWT, Wickett, Stripes, ZK, Tapestry, etc. all still exist -- and are more popular than JSF -- all without a spec.

Some specs have succeeded, due to their simplicity and natural interface boundary (usually a network connection requiring a driver of sorts). These include Servlet, JDBC and JMS. Even though they're not the nicest, they're simple and necessary. Yet they too differ in many ways, especially JDBC. JPA has a chance, but only because they essentially took the two most popular frameworks that weren't specs and made them into a spec... nobody will be winning any innovation awards for that one.

The spec doesn't guarantee anything. Kind of like a green light doesn't guarantee that cars won't be driving through the opposing red light at an intersection... do you not check?

The only thing that defines how a framework will work is the framework itself -- spec or not. The only protection you have is your own unit, functional and integration tests -- which you need anyway, as it's also the only way you'll know if YOUR code works."

iBaGuice 1.0-beta-2 is out!

2010-03-03T11:05:00.002+01:00

The iBaGuice team is pleased to announce that the 1.0-beta-2 version
of iBaGuice was released yesterday, you can check it out here.

Major news are:

apache ibatis dependency has been upgrated to 3.0-beta-10;

apache commons-dbcp dependency has been upgrated to 1.3 and planned
to support apache commons-dbcp 1.4;

@Transactional behavior has been modified according to new
apache-ibatis APIs to support transaction isolation levels;

new cache module added, based on Hazelcast, useful to realize
high-scalable applications.

More news are coming for the beta-3:

new cache module, based on JBoss INFINISPAN;

first apache-ibatis interceptor plugin, based on
Hibernate-Validator, the JSR303 (Bean Validation) reference
implementation.

Don't forget to join the Google iBaGuice Group: questions, feedbacks, suggestions, patches, design discussion, nice to have list, whatever you need, are always more than appreciated :)

Don't create loggers by hand, use sli4j

2010-02-13T11:56:00.003+01:00

Yesterday in the night I just released my last effort I realized with my friend Marco: sli4j that stands for Simple Logging Injector 4 Java.

The projects aims to delegate to Google Guice (what else?) the Logger creation and injection, depending on your preferred Logging framework. By default, sli4j provides modules to bind Loggers to

Java Utils Logging;

Apache commons-logging;

Apache log4j;

Simple Logging Facade for Java slf4j, with Logback support.

But more exigent users that have the need to use their custom logging framework, can easily extend the sli4j core module and with 2 simple steps can create their corporate logging injector.

Every kind of feedback is more thank welcome :)

Tired of default maven site theme? You don't know fluido-skin

2010-02-12T09:18:00.004+01:00

I'm a software passionate at 360°, and I always take care about styles, from coding style to documentation style.

For this reason I started adoring Apache Maven, not just because makes easier the software lifecycle, but also because it's the first tool that allowed me creating enhanced documentation in a standard-de-facto way!!!

But even that more than satisfied, I got tired soon using the default Maven skin stile and started thinking about how to improve it...

So, first I switched to Apache Commons skin: nicer and more elegant, but again, after few months I got tired... the available skins I found on Codehaus wiki didn't match with my wishes, so my last bullet to shoot was creating my own skin.

Fortunately I found the online Sonatype's guide and after 2 hours of work I created the Fluido skin, with enhanced features:

rounded corners, via Nifty Corners Cube;

syntax highlighting of source code snippets, via google-code-prettify;

accurated choice of fonts and colors. :P

Here you can see how it looks, and if you like it you've to follow these simple steps: first of all, just add the fluido-skin repository in your pom.xml:


<repositories>
    ....
    <repository>
        <id>fluido-skin-repository</id>
        <name>fluido-skin Repository for Maven</name>
        <url>http://fluido-skin.googlecode.com/svn/repo</url>
        <layout>default</layout>
    </repository>
    ....
</repositories>

Then, in your site.xml add the skin:


<project name="XXXXXXXX">
    ....
    <skin>
        <groupId>com.google.code</groupId>
        <artifactId>fluido-skin</artifactId>
        <version>1.2</version>
    </skin>
    ....
</project>

and that's all! Generate you site and have fun with the new skin! :)

Let's get it on!

2010-02-03T20:41:00.002+01:00

As previously announced, today I started working as a Sourcesense staff member: I felt like the first day at school, but quite nicer and more interesting :)
And a new challenge was waiting for me: customizing JIRA and writing amazing plugin... let's get it on!!!

Enjoy the power of iBatis 3 + Guice 2!

2010-01-31T19:29:00.010+01:00

Both products don't need to be introduced, final version of iBatis 3 is going to be release soon and Guice 2 is widely used in production evironments, fist of all in Google itself.

Marco Speranza, a close friend of mine, and I, are great fan of these technologies and in our daily work we strongly use both frameworks; we both noticed we've been continuously repeating the same code in different projects, so during the Xmas vacations, during a rainy day, we started speaking on Skype about a possible solution to combine the 2 framework according to the DRY - Don't Repeat Yourself - principle, realizing something that alleviate us the task to reduce and simplify the applications code, injecting the org.apache.ibatis.session.SqlSessionFactory via @com.google.inject.Injector.

That day we gave born to iBaGuice (still snapshot!), the perfect glue between the two more popular frameworks.

The first point of strength is the ability of creating the org.apache.ibatis.session.SqlSessionFactory through Google Guice, included in the core module, that binds magically all the required components, with a large support for 3rd parties developed Data Source and Transactions Managers. As reported in the official documentation, the typical use case shows how iBaGuice simplifies developers stuff:


import com.google.code.ibaguice.core.SqlSessionFactoryModule;
import com.google.inject.Guice;
import com.google.inject.Injector;
import com.google.inject.Provider;
import javax.sql.DataSource;
import org.apache.ibatis.session.SqlSessionFactory;
import org.apache.ibatis.transaction.TransactionFactory;

...

Class<? extends Provider<DataSource>> dataSourceProviderClass = [...];
Class<? extends Provider<TransactionFactory>> txFactoryProviderClass = [...];

Injector injector = Guice.createInjector(
    new SqlSessionFactoryModule(dataSourceProviderClass, txFactoryProviderClass),
    ...
);

SqlSessionFactory sessionFactory = injector.getInstance(SqlSessionFactory.class);

More interesting is, in our opinion, the @Transactional annotation handled via AOP included in the DAO module; code like


package com.acme;

import com.google.inject.Singleton;
import com.google.code.ibaguice.dao.*;

@Singleton
public final class FooDAOImpl extends AbstractDao implements FooDAO {

    public void doFooBar() throws Exception {
        SqlSession session = this.getSqlSessionFactory().openSession(ExecutorType.SIMPLE, TransactionIsolationLevel.READ_UNCOMMITED);
        try {
            FooMapper fooMapper = session.getMapper(FooMapper.class);
            fooMapper.doFoo();

            BarMapper barMapper = session.getMapper(BarMapper.class);
            barMapper.doBar();

            session.commit();
        } catch (Throwable t) {
            session.rollback();
            throw new Exception("Something went wrong", t);
        } finally {
            session.close();
        }
    }

}

easily becomes, using the TransactionalModule like this:


package com.acme;

import com.google.inject.Singleton;
import com.google.code.ibaguice.dao.*;

@Singleton
public final class FooDAOImpl extends AbstractTransactionalDao implements FooDAO {

    @com.google.code.ibaguice.dao.Transactional(ExecutorType.SIMPLE, TransactionIsolationLevel.READ_UNCOMMITED)
    public void doFooBar() {
        FooMapper fooMapper = this.getMapper(FooMapper.class);
        fooMapper.doFoo();

        BarMapper barMapper = this.getMapper(BarMapper.class);
        barMapper.doBar();
    }

}

Moreoved we added support for 3rd parties Data Sources:

C3P0;

Apache commons-dbcp;

and a large number of 3rd parties Cache implementations:

Ehcache;

Hazelcast;

JBoss Cache;

Memcached;

OSCache.

The project is Open Source released under the Apache License v2 and can be found on google-code. Feedbacks and contributions are more than welcome, for any question about iBaGuice you can join the Mailing List hosted on Google Groups.

Starting a new life

2010-01-29T23:50:00.002+01:00

Today, after exactly three years, Asemantics, the semantic web company where I've been worked, due to economical crisis, had to fire her employees, no one excluded, and at the same time, after several months where I've been worked for Goomradio, I terminated my consultant position...

But an incredible new adventure is waiting for me behind the corner: starting from February 3rd, I'll be officially part of the Sourcesense development team, an amazing group of "black belt" specialists of Open Source products... it seems I found a new home where work.

My name is Simone Tripodi, and this is my first post, looking forward my new professional life... welcome to my new blog.