how to generate barcode in vb.net 2008 Exploring class loading in Java

Creator DataMatrix in Java Exploring class loading

Figure 11.3 The class loader by default follows Parent First Delegation model. When a class is required, it first asks its parent to load the class.

which the JVM searches for classes. This approach is called the Parent First delegation model. Now that we ve reviewed the basics of Java class loading, let s quickly review how class loading works in a Java EE application.

As we discussed earlier, an EJB application may make use of third-party libraries. In order to enable that, most Java EE containers use sophisticated mechanisms to load classes from a variety of places. You may remember from previous discussions that we follow standard practices to package our application components into standard-compliant archives such as EAR, EJB -JAR, WAR, and so forth. Table 11.2 lists the code sources for commonly used Java EE modules. For simplicity we are ignoring resource adapter (RAR) modules.

Table 11.2 A standard archive may load classes either packaged inside it or from any other archives it is dependent on. Module EAR Code Sources 1. All JARs in the /lib directory of the EAR 2. Manifest Class-Path of any JARs in 1 1. EJB-JAR file itself 2. JARs referenced by manifest Class-Path of EJB-JAR 3. JARs referenced by manifest Class-Path of above JARs (in 2) 1. WEB-INF/classes 2. JARs in WEB-INF/lib 3. JARs referenced by manifest Class-Path of WAR 4. JARs referenced by manifest Class-Path of JARs in 2 and 3

The sooner you develop a good understanding of how the packaging standards work, the easier the whole packaging and deployment process will be.

Unfortunately, no Java EE specification provides a standard for class loading, and each application server implements class loaders in whatever way seems best to the vendor. However, Java EE defines the visibility and sharing of classes between different modules, and we can depict the dependency between different modules as shown in figure 11.4. As illustrated in figure 11.4, the EAR class loader loads all JARs in the lib directory that is shared between multiple modules. Typically a single EJB class loader loads all EJB classes packaged in all EJB -JAR modules. The EJB class loader is often the child of the application class loader, and loads all EJB classes. Because the EJB is a child to the EAR class loader, all classes loaded at the EAR level will be visible to the EJBs.

Figure 11.4 Illustration of class visibility of an EAR file containing multiple web modules, EJBs, and shared library modules. The EAR class loader loads the classes in the JARs packaged as library modules, and all classes loaded by the EAR class loader are visible to the EJBs. The classes loaded by EJB class loader are typically visible to the web module in most containers because the WAR class loader is a child of the EJB class loader.

EJBs are accessible from WAR modules. Furthermore, the EJB class loader is the parent of the WAR application class loader, and all EJB classes will be visible to the WAR module by default. So before we move on to packaging EJBs, let s recap how this is going to help in packaging EJB 3 applications. If you package classes in a specific EJB module,

it will probably be visible to only that module. If you want your classes (helper and utility) to be visible to all modules in the EAR file, you can package them as a library module in the EAR. Armed with this knowledge on class loading, we can now return to the discussion on packaging EJBs. First we ll talk about the packaging of session and message-driven beans, and quickly proceed to the packaging of persistence entities.