J2EE application server sample class loader hierarchy is shown below (Also refer to Q5 in Java section) As per the diagram the J2EE application specific class loaders are children of the “System –classpath” class loader.

When the parent class loader is above the “System –classpath” class loader in the hierarchy as shown in the diagram (i.e. bootstrap class loader or extensions class loader) then child class loaders implicitly have visibility to the classes loaded by its parents. When a parent class loader is below a “System -classpath” class loader in the hierarchy then the child class loaders will only have visibility into the classes loaded by its parents only if they

are explicitly specified in a manifest file (MANIFEST.MF) of the child class loader.

Example As per the diagram, if the EJB module MyAppsEJB.jar wants to refer to MyAppsCommon.jar and

MyAppsUtil.jar we need to add the following entry in the MyAppsEJB.jar’s manifest file MANIFEST.MF.

class-path: MyAppsCommon.jar MyAppsUtil.jar

Bootstrap(JVM) (rt.jar, i18.jar) Extensions(JVM) (lib/ext) System(JVM) (-classpath) Application class loader (EAR) Application class loader (EAR)

EJB class loader EJB class loader

WAR class

loader WAR classloader

WAR class loader

Each EAR gets its own instance of class loader

All the EJB jars in a ear file share the same EJB class loader. Each WAR gets its own instance of class loader. The WEB-INF/lib libraries are specific to each WAR

Note: Application vendor's Server class loader hierarchy might slightly vary .

J2EE application server sample class loader hierarchy MyApps.ear

MyAppsUtil.jar MyAppsCommon.jar MyAppsEJB.jar MyAppsWeb.war

This is because the application (EAR) class loader loads the MyAppsCommon.jar and MyAppsUtil.jar. The EJB class loader loads the MyAppsEJB.jar, which is the child class loader of the application class loader. The WAR class loader loads the MyAppsWeb.war.

Every J2EE application or EAR gets its own instance of the application class loader. This class loader is also responsible for loading all the dependency jar files, which are shared by both Web and EJB modules. For

example third party libraries like log4j, utility (e.g. MyAppsUtility.jar) and common (e.g. MyAppsCommon.jar) jars

etc. Any application specific exception like MyApplicationException thrown by an EJB module should be caught by a Web module. So the exception class MyApplicationException is shared by both Web and EJB modules.

The key difference between the EJB and WAR class loader is that all the EJB jars in the application share the

same EJB class loader whereas WAR files get their own class loader. This is because the EJBs have inherent

relationship between one another (i.e. EJB-EJB communication between EJBs in different applications but hosted on the same JVM) but the Web modules do not. Every WAR file should be able to have its own WEB-INF/lib third

party libraries and need to be able to load its own version of converted logon.jsp servlet. So each Web module is isolated in its own class loader.

So if two different Web modules want to use two different versions of the same EJB then we need to have two different ear files. As was discussed in the Q5 in Java section the class loaders use a delegation model where the child class loaders delegate the loading up the hierarchy to their parent before trying to load it itself only if the parent can’t load it. But with regards to WAR class loaders, some application servers provide a setting to turn this behavior off (DelegationMode=false). This delegation mode is recommended in the Servlet 2.3 specification.

As a general rule classes should not be deployed higher in the hierarchy than they are supposed to exist. This is because if you move one class up the hierarchy then you will have to move other classes up the hierarchy as well. This is because classes loaded by the parent class loader can’t see the classes loaded by its child class loaders (uni-directional bottom-up visibility).

Tech Tip #4:

Q. What do the terms internationalization(i18n) and localization(l10n) mean, and how are they related? Localization (aka l10n, where 10 is the number of letters between the letter ‘l’ and the letter ‘n’ in the word localization ) refers to the adaptation of an application or a component to meet the language, cultural and other requirements to a specific locale (i.e. a target market). Internationalization (aka i18n, where 18 is the number of letters between the letter ‘i’ and the letter ‘n’ in the word internationalization) refers to the process of designing a software so that it can be localized to various languages and regions cost-effectively and easily without any engineering changes to the software. A useful website on i18n is http://www.i18nfaq.com.

Q. What are the characteristics of an internalized program?

-- The same executable can run worldwide without having to recompile for other or new languages.

-- Text messages and GUI component labels are not hard-coded in the program. Instead they are stored outside the source code in “.properties” files and retrieved dynamically based on the locale.

-- Culturally dependent data such as dates and currencies, appear in formats that conform to end user's region and language. (e.g. USA Æ mm/dd/yyyy, AUS Æ dd/mm/yyyy).

Q. What are the different types of data that vary with region or language?

Messages, dates, currencies, numbers, measurements, phone numbers, postal addresses, tax calculations, graphics, icons, GUI labels, sounds, colors, online help etc.

Q. What is a Locale? A Locale has the form of xx_YY (xx – is a two character language code && YY is a two character country code. E.g. en_US (English – United States), en_GB (English - Great Britain), fr_FR (french - France). The java.util.Locale class can be used as follows:

Locale locale1 = new Locale(“en”, “US”); Locale locale2 = Locale.US;

Locale locale3 = new Locale(“en”);

Locale locale4 = new Locale(“en”, “US”, “optional”); // to allow the possibility of more than one // locale per language/country combination. locale2.getDefault().toString(); // en_US

locale2.getLanguage(); // “en” locale2.getCountry(); // ”US”

Resource bundles can be created using the locale to externalize the locale-specific messages:

Message_en_US.properties

Greetings = Hello

Message_fr_FR.properties

Greetings = Bonjour

Locale currentLoc = new Locale(“fr”, “FR”);

ResourceBundle messages = ResourceBundle.getBundle(“Message”, currentLoc); System.out.println(messages.getString(“Greetings”)); //prints Bonjour

Note: When paired with a locale, the closest matching file will be selected. If no match is found then the default file will be the Message.properties. In J2EE, locale is stored in HTTP session and resource bundles (stored as *.properties files under WEB- INF/classes directory) are loaded from the web.xml deployment descriptor file. Locale specific messages can be accessed via tags (e.g. Struts, JSTL etc).

The

java.text

default locale, but this can be overridden. E.g. NumbeFormat, DateFormat, DecimalFormat, SimpleDateFormat, MessageFormat,

ChoiceFormat, Collator (compare strings according to the customary sorting order for a locale) etc.

DateFormat:

Date now = new Date(); Locale locale = Locale.US;

String s = DateFormat.getDateInstance(DateFormat.SHORT, locale).format(now);

NumberFormat:

NumberFormat usFormat = NumberFormat.getInstance(Locale.US); String s1 = usFormat.format(1785.85); // s1 Æ 1,785.85

NumberFormat germanyFormat = NumberFormat.getInstance(Locale.GERMANY); String s2 = germanyFormat.format(1785.85); // s2 Æ 1.785,85

To use default locale:

NumberFormat.getInstance(); NumberFormat.getPercentInstance(); NumberFormat.getCurrencyInstance();

To use specific locale:

NumberFormat.getInstance(Locale.US);

Enterprise - Servlet

Desktop applications (e.g. Swing) are presentation-centric, which means when you click a menu item you know which window would be displayed and how it would look. Web applications are resource-centric as opposed to being presentation-centric. Web applications should be thought of as follows: A browser should request from a server a resource (not a page) and depending on the availability of that resource and the model state, server would generate different presentation like a regular “read-only” web page or a form with input controls, or a “page-not-found” message for the requested resource. So think in terms of resources, not pages.

Servlets and JSPs are server-side presentation-tier components managed by the web container within an application server. Web applications make use of http protocol, which is a stateless request-response based paradigm.