In my case, I wanted to use the annotations part of the JSR107 because I find them to be more elegant than a pure code solution (understand, you can put cache in your app without changing the logic, you just annotate your business methods, and woosh, you have cache set up).

But the JSR107 annotations implementations are DI framework dependant. And untill some days ago, only Spring and CDI implementation were provided.

I twitted to search any volunteers that might be interested in contributing (with or without me) to a Guice implementation.

Some hours laters, some commits from Michael Stachel were pushed by Alex Snaps to the github repo and here they are, the JSR 107 annotations for Guice were available.

I’d like to show you how you can use them.

The full source code is available here as a Mercurial repository on Bitbucket.

I’m using Maven, so here is the dependency part of the pom

        
            com.google.inject
            guice
            ${guice.version}
        
        
        
            net.sf.ehcache
            ehcache-jcache
            1.4.0-beta1
        
        
            javax.cache.implementation
            cache-annotations-ri-guice
            0.5-SNAPSHOT
        

You can see here that I’m using the latest snapshot of the cache-annotations-ri-guice artifact (0.5-SNAPSHOT as I’m writing this post). I don’t know if the snapshots are available somewhere, so I just cloned the corresponding git repositories and installed the snapshots locally. To be more precise, you will need to clone the jsr107-spec repo to build and install locally the jsr107 api artifacts that are needed by the jsr107 Reference Implementation artifacts, among which you’ll find the cache-annotations-ri-guice artifact.

Now, let’s write a basic UserService interface (ok, you don’t need an interface actually):

package net.awl.ismp.guice.jsr107;

import java.util.List;

/**
 *
 * @author looztra
 */
public interface UserService {
    public User getUserById(int id, int callId);
    public List<User> getUserByLastName(String name, int callId);
    public boolean calledBy(int callId);
}

The UserService makes reference to a User class:

package net.awl.ismp.guice.jsr107;

import java.io.Serializable;
import lombok.Data;

/**
 *
 * @author looztra
 */
@Data
public class User implements Serializable {
    private int id;
    private String firstName;
    private String lastName;
    private int age;
}

People that follow may have spotted that I was too lazy to write the accessors and that I chose to use the Lombok @Data annotation instead.

Here is the main part of a simple implementation of the basic UserService:

package net.awl.ismp.guice.jsr107;

import java.util.*;
import javax.cache.annotation.CacheKeyParam;
import javax.cache.annotation.CacheResult;
import lombok.extern.slf4j.Slf4j;

/**
 *
 * @author looztra
 */
@Slf4j
public class SimpleUserService implements UserService {

    private Map<Integer, User> users = new HashMap<Integer, User>();
    private List<Integer> callers = new ArrayList<Integer>();

    public SimpleUserService() {
        initContent();
    }

    @Override
    @CacheResult(cacheName = "getUserById")
    public User getUserById(@CacheKeyParam int id, int callId) {
        log.info("getUserById(): business method called for id (" + id + ") and callId (" + callId + ")");
        registerCaller(callId);
        if (id >= 0 && id < 100) {
            return users.get(id);
        } else {
            return null;
        }
    }

    @Override
    @CacheResult(cacheName = "getUserByLastName")
    public List<User> getUserByLastName(@CacheKeyParam String name, int callId) {
        log.info("getUserByLastName(): business method called for name <" + name + "> and callId <" + callId + ">");
        registerCaller(callId);
        List<User> matches = new ArrayList<User>();
        for (Map.Entry<Integer, User> entry : users.entrySet()) {
            User potentialMatch = entry.getValue();
            if (potentialMatch.getLastName().contains(name)) {
                matches.add(potentialMatch);
            }
        }
        return matches;
    }
...
}

The initContent() an the registerCaller() method are only utilities methods (full source code available here).

The interesting parts are the two annotations @CacheResult and @CacheKeyParam.

Straight from the javadoc: When a method annotated with @CacheResult is invoked a CacheKey will be generated and javax.cache.Cache#get(Object) is called before the invoked method actually executes. If a value is found in the cache it is returned and the annotated method is never actually executed. If no value is found the annotated method is invoked and the returned value is stored in the cache with the generated key.

The @CacheResult is then a very simple way to set up a Read-Through cache.

The @CacheKeyParam is used to specify which subset of the method params are to be used as part of the CacheKey (by default, all the method params are used).

Those 2 annotations are not the only one existing of course. You could use @CachePut to implement a Write-Through cache for instance.

Before it can work as expected, don’t forget to register the CacheAnnotationsModule so that Guice injector can use the jsr107 annotations.

...
@BeforeClass
    public void setUp() {
        Injector injector = Guice.createInjector(new MyModule(),new CacheAnnotationsModule());
        service = injector.getInstance(UserService.class);
    }
...

MyModule being a very simple Guice module matching my simple needs:

package net.awl.ismp.guice.jsr107;

import com.google.inject.AbstractModule;

/**
 *
 * @author looztra
 */
public class MyModule extends AbstractModule {

    @Override
    protected void configure() {
        bind(UserService.class).to(SimpleUserService.class);
    }

}

A simple unit test to see it in action

    @Test
    public void testGetIdTwice() {
        Assert.assertNotNull(service);
        int callId = getCallerId();
        log.info("testGetIdTwice(): calling the service the first time with callerId <" + callId + ">");
        User found = service.getUserById(testGetIdTwice_SEARCHED_ID, callId);
        Assert.assertNotNull(found);
        log.info("testGetIdTwice(): found user <" + found + ">");
        // check that we went through the business method the time
        Assert.assertTrue(service.calledBy(callId));
        //
        int callId2 = getCallerId();
        log.info("testGetIdTwice(): calling the service the second time with callerId <" + callId2 + ">");
        User found2 = service.getUserById(testGetIdTwice_SEARCHED_ID, callId2);
        Assert.assertNotNull(found2);
        // check that we did not go through the business method this time
        Assert.assertFalse(service.calledBy(callId2));

    }

Feel free to get the full source code that is available here as a Mercurial repository on Bitbucket.

You can do that using Hooks with mercurial but the built-in mercurial web server provides RSS feeds of changes in every repository. Simply subscribe to the rss feed provided at your repository url + /rss-log/ and that's it.

Enjoy

• change the windows shortcut (that is global to windows, i.e. that will surcharge any application shortcut)
• unregister the layout that you never use

In both cases, go to Control Pannel > Regionnal Settings > Languages > Details.

The project has been “mavenized” and moved to SVN (ok, maybe we should have switched directly to Git, please don’t tell Linus we are still using SVN).

A version 0.3 has been released, a full changelog can be found here. The main changes are:

• a patch to fix the case of multiple datasources has been applied (initialy provided by Juraj Sucik).
• supports version 3 rrd files (jRRD v0.1 only had support for version 1 rrd files)
• x86_64 files (only tested on linux 64bits plateform, if you have access to other 64bits plateform, please contact us)

The project is not really active because in its current state, it fits our needs, so fill free to wake it up and send us your feature requests.

C:\Cygwin\bin\rxvt.exe -g 120×70+75+-1  -sl 1500 -fn courier -bg black -fg grey -sr -e bash –login -i

but all you get is big window with strange spacing between chars:

.
Ok, it’s time to customize some stuff. Open a cygwin shell (or an ugly uncustomized rxvt), go to your home directory, and create/edit your .Xdefaults file to fit this one:

#Rxvt.reverseVideo:      true
Rxvt.scrollBar_right:   false
Rxvt.saveLines:         2048
Rxvt.font:              "Lucida Console-12"

Then edit your shortcut to something similar to this one:

C:\cygwin\bin\rxvt.exe -display :0 -bg black -fg grey -tn rxvt -sr -sl 1500 -g "140x60+1+-1" -e /usr/bin/bash --login -i

If you need to adjust the size of the window, you can change the -g “140×60+1+-1″ values.

You should now get something much more like that:



Enjoy!

All you’ll need is a piwik siteId, the piwik server name and path of your piwik installation. And the Piwik Analytics plugin for Hudson that you can download here (save as…) till there is an official version available (maybe some more tests needed, any feedback will be appreciated!)

Update 2009-11-03: I fixed the mime type for hpi files so no more Save as should be needed.
Update 2009-11-04: some minor changes: french translations and the possibility to add download extensions (see

http://piwik.org/docs/javascript-tracking/

Update 2009-11-06: fixed the package to be compatible with jdk 1.5
Update 2009-11-07: the plugin has been officially released and should be available in you admin plugin list.

La raison est simple, le kernel livré avec la fc11 est un 2.6.29, qui n’était pas encore sorti lorsque le player 2.5.2 est sorti.

Toutes les infos et le patch a appliquer se trouvent par là.

Après application du patch, ça devrait donner:

Starting VMware services:
Virtual machine monitor                                 [  OK  ]
Virtual machine communication interface                 [  OK  ]
Blocking file system                                    [  OK  ]
Virtual ethernet                                        [  OK  ]
Shared Memory Available                                 [  OK  ]

et zou.

vmware-6.5.2-modules-2.6.29-fix.sh
vmware-6.5.2-modules-2.6.29-fix.patch

If you’ve just upgraded your fedora install to version 11 and that you (have to) use VMware player (despite VirtualBox works very well), you will encounter a small problem: additionnal kernel modules needed by the vmware install won’t compile.

Indeed, the kernel bundled with fc11 is a 2.6.29, that wasn’t out when vmware player 2.5.2 was released.

All informations and a patch to apply are provided here.

Let’s apply the patch and enjoy:

Starting VMware services:
 Virtual machine monitor                                 [  OK  ]
 Virtual machine communication interface                 [  OK  ]
 Blocking file system                                    [  OK  ]
 Virtual ethernet                                        [  OK  ]
 Shared Memory Available                                 [  OK  ]

that's all folks!

vmware-6.5.2-modules-2.6.29-fix.sh
vmware-6.5.2-modules-2.6.29-fix.patch

Jusqu’à ce jour. Je viens de découvrir (shame on me?) qu’il est parfois nécessaire de ne pas explicitement forcer la valeur par défaut.

1er cas:

public class MotherClass {

public MotherClass(String… args) {
System.out.println(“MotherClass(): [BERORE CALL TO PREPARE] this:” + this);
prepare(args);
System.out.println(“MotherClass(): [AFTER CALL TO PREPARE] this:” + this);
}

public void prepare(String… args) {

this.member0_1 = args[0];
this.member0_2 = args[1];
System.out.println(“MotherClass.prepare(): this:” + this);
}


public String toString() {
return ”MotherClass <member0_1=” + member0_1 + ”, member0_2=” + member0_2 + ”>”;
}

protected String member0_1;
protected String member0_2 = ”initialized”;

public static void main(String[] args) {
MotherClass mc = new MotherClass(new String[] { ”first”, ”second” });
System.out.println(“main(): mc:” + mc);
}
}

Si on lance le main, ça donne:

MotherClass(): [BERORE CALL TO PREPARE] this:MotherClass <member0_1=null, member0_2=initialized>
MotherClass.prepare(): this:MotherClass <member0_1=first, member0_2=second>
MotherClass(): [AFTER CALL TO PREPARE] this:MotherClass <member0_1=first, member0_2=second>
main(): mc:MotherClass <member0_1=first, member0_2=second>

Dans ce cas, rien de particulier, la classe se comporte comme on peut s’y attendre, que la variable d’instance ait été initialisée (member0_2) ou pas (member0_1).

Etendons maintenant cette classe:

public class ClassThatExtends extends MotherClass {

public ClassThatExtends(String… args) {
super(args);
System.out.println(“ClassThatExtends(): [AFTER super()] this:” + this);
}

public void prepare(String… args) {
if (args.length == 4) {
this.member0_1 = args[0];
this.member0_2 = args[1];
this.member1_1 = args[2];
this.member1_2 = args[3];
}
System.out.println(“ClassThatExtends.prepare(): this:” + this);
}

public String toString() {
return ”ClassThatExtends <member0_1=” + member0_1 + ”, member0_2=” + member0_2
+ ”, member1_1=” + member1_1 + ”, member1_2=” + member1_2 + ”>”;
}

private String member1_1;
private String member1_2 = ”initialized”;

public static void main(String[] args) {
ClassThatExtends cte = new ClassThatExtends(new String[] { ”first”, ”second”, ”third”,
“fourth” });
System.out.println(“main(): cte:” + cte);
}
}

Si on lance le main:

MotherClass(): [BERORE CALL TO PREPARE] this:ClassThatExtends <member0_1=null, member0_2=initialized, member1_1=null, member1_2=null>

ClassThatExtends.prepare(): this:ClassThatExtends <member0_1=first, member0_2=second, member1_1=third, member1_2=fourth>

MotherClass(): [AFTER CALL TO PREPARE] this:ClassThatExtends <member0_1=first, member0_2=second,member1_1=third, member1_2=fourth>

ClassThatExtends(): [AFTER super()] this:ClassThatExtends <member0_1=first, member0_2=second,member1_1=third, member1_2=initialized>

main(): cte:ClassThatExtends <member0_1=first, member0_2=second, member1_1=third, member1_2=initialized>

WTF? member1_1 qui n’a pas été explicitement initialisée dans la classe fille a gardé la valeur fixée lors de l’appel du constructeur, par contre, member1_2 qui a été explicitement initialisée a été écrasée après avoir été valorisée dans le constructeur!

Les variables d’instance d’une classe “fille” sont donc initialisées APRES la chaîne des appels des constructeurs.

Dans le cas où la variable n’est pas explicitement initialisée lors de sa déclaration et que la variable est valorisée dans le constructeur, la valeur de la variable d’instance sera conservée. Dans le cas où la variable d’instance est explicitement initialisée lors de sa déclaration et qu’elle est valorisée dans le constructeur, la valeur est écrasée par la valeur d’initialisation spécifiée!

Fichtre! En voila donc un comportement pas forcément trivial… Si quelqu’un arrive à me trouver le bout de doc chez Java (ou ailleurs) que j’ai du louper, je suis preneur.

• http://internna.blogspot.com/2009/04/web-framework-comparison-prototyping.html
• http://java.dzone.com/tips/java-web-frameworks-survey
• http://docs.google.com/Doc?id=ajgdx7ccvkxg_50ccp25f