PriDE Design Patterns:
Initialization for J2SE and J2EE

The Introduction explained already how to initialize PriDE for J2SE, J2EE, and Web environments. However, in an application server it is important to find a suitable place for such a quasi-static initialization. As a J2EE application must not make any assumptions on the distribution of application components on the system (i.e. potentially in a multi-node server cluster), every component must ensure a propper PriDE initialization by itself if it wants to work with the toolkit. Session EJBs may perform a PriDE initialization on their instantiation which causes the methods ejbCreate() and setSessionContext() to be called:
 
class MyEJB extends SessionBean {
    public void ejbCreate() throws CreateException {
        try {
            PriDEConfig.init();
        }
        catch(Exception x) {
            throw new CreateException();
        }
    }

    //...
}

Of course the initialization of a session EJB instance occurs much more often then an initialization of PriDE is required. To avoid a loss of performance by repeated unnecessary initializations, the implementation of the initialization procedure should be aware if it has already been run. The procedure shoult be thread-safe as it may be called by multiple EJB instances at a time. The class de.mathema.util.Singleton, distributed in the PriDE library may be used for this purpose as follows:
 
public class PriDEConfig {
  private final static Singleton _singleton =
    new Singleton() {
      protected Object createInstance() throws Exception {
        ResourceAccessorJ2EE accessor = new ResourceAccessorJ2EE
            (System.getProperties());
        DatabaseFactory.setResourceAccessor(accessor);
        DatabaseFactory.setDatabaseName("jdbc.mydb");
        return accessor;
      }
    };

   public static void init throws Exception {
        _singleton.getInstance();
   }
}

An embedding like this can be used both inside and outside an application server. This is especially of interest if the implementation of a J2EE component like an EJB should also be used outside its container (e.g. for test purposes within unit tests, see the article "Testen von EJBs ohne Application Server", JavaMagazin 11.2002). If the working context can somehow be extracted from some meta data (see e.g. the pattern 'EJBFactory', MATHEMA, 2001), the configuration can be selected dynamically without changing the implementation code. The following example illustrates this idea:
 
public class PriDEConfig {
    private final static Singleton _singleton =
        new Singleton() {
            private ResourceAccessor initJ2EE() throws Exception {
                DatabaseFactory.setDatabaseName("jdbc.mydb");
                return new ResourceAccessorJ2EE(System.getProperties());
            }

            private ResourceAccessor initJ2SE() throws Exception {
                DatabaseFactory.setDatabaseName("jdbc:odbc:mydb");
                return new ResourceAccessorJ2SE (System.getProperties());
            }

            private boolean isJ2EE() { return false; } // find out somehow

            protected Object createInstance() throws Exception {
                ResourceAccessor accessor = isJ2EE() ? initJ2EE() : initJ2SE();
                DatabaseFactory.setResourceAccessor(accessor);
                return accessor;
            }
        };

    public static void init() throws Exception {
        _singleton.getInstance();
    }
}

When using PriDE in a servlet engine, it is recommended to use a similar solution as for EJB environments. A singleton initializer, can be run from the servlets' init method, making use of the ResourceAccessorWeb. In Web environments it is also recommended to substitute PriDE's default exception listener by an implementation which does not shout down the application.
An example servlet can be found in examples/servlet. The complete source code for the examples above can be found in examples/init.


Home Introduction Javadoc