El péndulo de Foucault

El fenómeno se desarrolla con calma; es inevitable, irresistible ... Viéndolo nacer y crecer, nos damos cuenta de que no está en la mano del observador acelerarlo o frenarlo ... Todo el mundo, en su presencia ... se queda pensativo y callado durante unos instantes y por lo general se va con una sensación más apremiante e intensa de nuestra incesante movilidad en el espacio.

Jean-Barnard-Léon Foucault

(Extraido de Historias de la ciencia)

Lookup extensions

Thanks to Emilian Bold, who appoints me a reference to this page Lookup and Service Installation, I am able to do a little more things.
The question comes when you have many status line elements and want to show them in a desired order. The answer is in this Emilian's blog entry and also in the later link.

Thread pools

Here is a good article that describes the importance and implications using pool threads.
http://www-128.ibm.com/developerworks/library/j-jtp0730.html

Are you creating any kind of applications that needs to create variable number of threads to get resources? If so, then perhaps you need to read this.

Bye Properties, hello Preferences

Since version 1.4.2 Java platform offers the Preferences API which intended to substitute and improve the older Properties API.

http://java.sun.com/j2se/1.5.0/docs/guide/preferences/index.html#prefs-other
http://www.onjava.com/pub/a/onjava/synd/2001/10/17/j2se.html

EJB3 and dependency injection

Mistakes are a way to learn if one has enough persistence to find the solution.
Recently, in my adventure with the EJB3 I learn bit more.

Suposse you have a session bean named A_Bean. Inside it you can use anotations like @Resource, @PersistenceContext, ...
Suposse you have another bean named B_Bean needed by A_Bean in some method. Also B_Bean can have it own @Resource and @PersistenceContext annotations.

To do that, you have to options:

1. Create the B_Bean by your hand,
2. Left the container create a B_Bean instance and inject it in your code.
   

Lets analize the first case with the next code:

@Stateless
public class A_BeanImpl implements A_Bean {

@PersistenceContext
private EntityManager em;

private B_Bean bbean;

public void foo() {
  bbean = new B_BeanImlp();
  bbena.foo();
}
}

@Stateless
public class B_BeanImpl implements B_Bean {

@PersistenceContext
private EntityManager em;

public void foo() {
  // Do something
}
}

Here, when the container instantiates an instance of our A_Bean, it is responsible to obtain a reference to an EntityManager and inject it.
Later in the A_Bean.foo() methos we are creating by our hand an instance of B_Bean. This means the container hadn't had nothing to do with the instanciation and then, the B_Bean EntityManager reference is null, NULL !!!

The second method, let the container create the B_Bean instance is something like:

@Stateless
public class A_BeanImpl implements A_Bean {

@PersistenceContext
private EntityManager em;

@EJB
private B_Bean bbean;

public void foo() {
  bbena.foo();
}
}

@Stateless
public class B_BeanImpl implements B_Bean {

@PersistenceContext
private EntityManager em;

public void foo() {
  // Do something
}
}

Here, in the A_Bean.foo() method you can invoque a B_Bean method because the container was responsible to instantiate a B_Bean bean and inject it. Also, and the most important, the container has injected the EntityManager references into the B_Bean and they aren't null.