Java, a leading tool in transparent and dynamic classloaidng with the needed classes being loaded into the VM when need arises, has, nevertheless, a very weird drawback, regarding loading of a JDBC Driver class. There are two ways to do it: either to call a classloader directly or to load it using Class.forName. The problem is that the JDBC API DriverManager seems like not being able to find the class on its own, and in case if you are not loading the JDBC Driver class manually you’ll be given a notification of no suitable driver being found for the precise JDBC connection string.

And the reason this happens is that the static code blocks in the class are carried out when a class is being loaded by a classloader. Upon being loaded the JDBC Driver classes get themselves registered to the JDBC API, and right after got assigned to undertake database connection for some of JDBC connection strings.

When asking the JDBC API for a JDBC connection to a definite database, (for instance like this: DriverManager.getConnection ( “jdbc:mysql://dbhost/mydb” )), the driver manager will handle and implement the request in this way: it will iterate over all classloaded (registered) driver classes to decide upon what driver should handle the particular connection string.  It is noteworthy that only the Driver class of the JDBC driver needs to be classloaded, as all the other classes, necessary for JDBC connection, will be loaded when need be, since the driver alone needs to be registered with the JDBC Driver Manager.
Programming of an EJB you will have to write the following interfaces: the component one (remote or local), the home one (also remote or local) and a bean class.

The component interface (remote or local) and bean (which will deliver the services named in the component interface) correlate, without the bean class’s implementing its own component interface. And in order to check at compile time the proper business method implementation, use the EJC design pattern called Business Interface Pattern.

To do so, aggregate the necessary EJB methods with the business methods you need, splitting the coding like this:

MyComponentBusinessInterface.java
public interface MyComponentBusinessInterface {
public void myBusinessMethod ( String parameter );
}
MyComponentInterface.java
import javax.ejb.EJBLocalObject;
public interface MyComponentInterface extends EJBLocalObject, MyComponentBusinessInterface {
}

and you’ll get an actually empty component interface.