61Deploying miscellaneous applications

gets returned by the lookup method is a JNDI Context object—hence, the class cast

exception. The solution is to use the full EJB name, as follows:

MyEjb ejb = (MyEjb)ctx.lookup(“MyEjb/local”);

A second potential problem is that the name of the EJB might be MyEjb, but that’s for

the remote interface. In this case, you have to use the narrow method on the

RemoteObject class as follows:

Object obj = ctx.lookup(“MyEjb”);

MyEjb ejb = (MyEjb)RemoteObject.narrow(obj, MyEjb.class);

Another subtle cause for the class cast exception might be that the object was created using one class loader, and you’re attempting to cast it within a class loaded by

another class loader. For example, assume you obtained a collection called coll and

are extracting org.foo.Widget objects out of it using the following code:

Object obj = coll.get(i);

log.debug(“obj=” + obj.getClass()); org.foo.Widget w = (org.foo.Widget)obj;

When it executes, the code prints the following line in the log file:

...obj=org.foo.Widget

Yet, the third line of the code causes a class cast exception.

This usually happens if you package, within your application, a JAR file that’s

already provided by the application server. The object was probably created using the class as defined in the application server, and then the cast is being done using the class definition from your application. Even if the two classes are identical, because they’re handled by different class loaders, they’re considered to be different classes. The solution is to either identify a separate class loader repository for your application or to remove the duplicate class library from your application.

3.4

Deploying miscellaneous applications

You should now know all about deploying applications to the application server. You’re even prepared for a visit from Murphy. In the chapters that follow, we cover sev- eral types of applications. But before we get to them, some application types don’t need a whole chapter to describe, so we cover them here. These applications are data sources and Hibernate archives.

3.4.1 Deploying data sources

At some point in time, you’ll want to access data in a database, and you’ll require some mechanism to do this. Your application could use Java Database Connectivity

(JDBC) to access the database directly; but, that has one fairly major problem—estab-

lishing a connection with the database is an expensive operation. And with a web application, you might find that a significant amount of time is spent hitting the data- base, so you might want to avoid having to frequently reestablish connections.

The solution to this problem is to let the application server manage your database connections using a data source. The application server can then manage the data- base connections by pooling them and by providing connections to the application when it needs them. The question then becomes: how does one declare, or deploy, a data source to the application server?

The answer is to create, and then deploy, a *-ds.xml file. You can use any name for

the file that you like, as long at the suffix is –ds.xml. Listing 3.2 shows an example.

<datasources> <local-tx-datasource> <jndi-name>MySqlDS</jndi-name> <connection-url>jdbc:mysql://mysql-hostname:3306/jbossdb ➥ </connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>x</user-name> <password>y</password> <min-pool-size>5</min-pool-size> <max-pool-size>20</max-pool-size> <idle-timeout-minutes>0</idle-timeout-minutes> <blocking-timeout-millis>5000</blocking-timeout-millis> <exception-sorter-class-name> ➥ org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter ➥ </exception-sorter-class-name>

<check-valid-connection-sql>SELECT COUNT(*) FROM FooBar </check-valid-connection-sql>

<metadata>

<type-mapping>MySQL</type-mapping> </metadata>

<connection-property name="xxx" type="java.lang.String">yyy

➥ </connection-property> </local-tx-datasource> </datasources>

The <local-tx-datasource> tag defines a particular type of data source that handles local transactions. Three different data source types are available, each of which han- dles transactions differently. Table 3.4 describes each type.

Listing 3.2 Example *-ds.xml file

Table 3.3 Data source transaction types

Tag Description

<local-tx-datasource> Identifies a data source that uses transactions, even distributed trans- actions within the local application server, but doesn’t use distributed transactions among multiple application servers.

<no-tx-datasource> Identifies a data source that doesn’t use transactions. This option isn’t shown in the example, but would appear in place of the

<local-tx-datasource> tag.

<xa-datasource> Identifies a data source that uses distributed transaction among multi- ple application servers. This option isn’t shown in the example, but would appear in place of the <local-tx-datasource> tag.

63