For the configuration of the datasource two steps are required:

• Deployment of the Firebird RAR resource adapter (jaybird-*.rar)
• Creation of the firebird-ds.xml configuration

RAR Resource Adapter

The RAR Resource Adapter is a version of RDBMs drivers packaged in a special way, defined by the JCA specifcation. The
latest versions of Type 4 JCA-JDBC Firebird Driver (JayBird) can be downloaded from the IBPhoenix site. Inside of the downloaded archive you will find jaybird-*.rar (The version used during the creation of this tutorial was jaybird-2.1.6.rar). Since deployment in JBoss AS is performed by simple file copy, make sure to put the RAR-adapter-file into the deployment location of the application server. (e.G. ${JBOSS_ROOT}\server\default\deploy\).

After deployment, you can check the status of the resource adapter, by looking on the Administration Console of the JBoss (by default accessing the server URL http://localhost:8080/admin-console/ if run locally).

Datasource Description

After a successful deployment of the Resource RAR, the configuration of the datasource has to be created. The Firebird datasource configuration is supplied in a file, located in the default deployment location. JBoss AS auto-deplyoer will automatically look for the *-ds.xml files, so we name it e.G. firebird-ds.xml.

The following datasource configuration defines a local transactional datasource. You just need to replace placeholders USERNAME, PASSWORD and path to your database-file (In the used installation the file was located in: c:\databses\tesdb.fdb)

<?xml version="1.0" encoding="UTF-8"?>

  <!-- ==================================================================== -->
  <!-- New ConnectionManager setup for firebird dbs using jca-jdbc xa driver-->
  <!-- Build jmx-api (build/build.sh all) and view for config documentation -->
  <!-- ==================================================================== -->

<connection-factories>
	<local-tx-datasource>
		<jndi-name>DataSourceFirebirdDS</jndi-name>
		<connection-url>jdbc:firebirdsql:localhost/3050:c:${/}databses${/}tesdb.fdb</connection-url>
		<driver-class>org.firebirdsql.jdbc.FBDriver</driver-class>
		<transaction-isolation>TRANSACTION_REPEATABLE_READ</transaction-isolation>
		<connection-property name="lc_ctype" type="java.lang.String">ISO8859_1</connection-property>
		<connection-property name="maxStatements">10</connection-property>
		<user-name>USERNAME</user-name>
		<password>PASSWORD</password>
		<min-pool-size>0</min-pool-size>
		<max-pool-size>10</max-pool-size>

		<blocking-timeout-millis>5000</blocking-timeout-millis>

		<idle-timeout-minutes>15</idle-timeout-minutes>
		<check-valid-connection-sql>SELECT CAST(1 as INTEGER) FROM rdb$database</check-valid-connection-sql>
		<track-statements>false</track-statements>
		<prepared-statement-cache-size>0</prepared-statement-cache-size>
		<metadata>
			<type-mapping>Firebird</type-mapping>
		</metadata>
	</local-tx-datasource>
</connection-factories>

Usage

The datasource in the example above is registered in the java JNDI namespace and is called DataSourceFirebirdDS. In the source code, this resource should be accessible via java:/DataSourceFirebirdDS. Here is the example using Dependency Injection (DI):

@Ressource(mappedName = "java:/DataSourceFirebirdDS")
private DataSource firebirdDataSource;

In order to use the datasource in a JPA, the persistence unit has to be configured. For example, for using Hibernate, the following persistence unit can be configured.

...
<persistence-unit name="testunit">
	<jta-data-source>java:/DataSourceFirebirdDS</jta-data-source>
	<provider>org.hibernate.ejb.HibernatePersistence</provider>
	...
	<properties>
		<property name="hibernate.dialect" value="org.hibernate.dialect.FirebirdDialect"/>
		<property name="hibernate.show_sql" value="true" />
		...
	</properties>
</persistence-unit>
...

Then in the DAO for manipulation of Persistent Entities, the Persistence Context can be injected by:

@Stateless
public class TestDAOBean implements TestDAO {

	@PersistenceContext(unitName = "testunit")
	private EntityManager manager;

	...
}

Have fun and please provide some feedback.

[wscompile] wscompile ...\env\java\1.4.2_03\jre\bin\classpath-classpath D:\workspaces\general\lib\bla.bo-0.0.1.jar; ... D:\workspaces\general\lib\... jar.0.5.5

In this line, the classpath of wscompile is printed.

The build script uses configured Apache Ant in version 1.6.5. I tried to start it with Java in versions 1.4.2 und 1.6.0.10. Both works in Europa (Eclipse 3.3.x) but don’t work in Ganymede (Eclipse 3.4.x), except for the first run. It seems that Ganymede provides a different handling for Ant scripts. Every first start of an Ant build script produces new “External Tool Configuration” (if not already there). If this configuration already exists, wscompile task doesn’t work!

This means my build script with wscompile task works only once, every first time after deleting the “External Tool Configuration”. I could live with that if I wouldn’t need that configuration. But I need that configuration to use different java version that is the workspace default.

Do anyone know how to fix that?
Here is my task definiton.

<taskdef name="wscompile"
		classname="com.sun.xml.rpc.tools.ant.Wscompile"
		classpathref="class.path.jwsdp"
		/>

and also task usage in the script

<wscompile fork="true" import="true" base="java/class" sourceBase="java/generated" verbose="true" features="documentliteral, wsi, searchschema, serializeinterfaces, explicitcontext" mapping="java/generated/META-INF/jaxrpc-mapping.xml" config="metadata/wsdl-config.xml" xSerializable="true">
	<classpath>
		<path refid="class.path.local" />
		<path refid="class.path.ant" />
		<pathelement path="${java.class.path}" />
	</classpath>
</wscompile>

Comments are welcome.

Yesterday I have already transferred some articles from my old wiki of my personal page to techjava wiki. My wiki was made several years ago, during my Business Informatics Study and was mostly in German. I think such information is better situated for Techava project, than for my personal Homepage. Now it’s starting point of the German part of our Techwiki. So I have to go critical through the articles to bring them on the latest state. But that is exactly what wiki is perfect situated for.

Main topics are: Distributed Systems, Middleware and basics of Web Services.

Enjoy and let us know if something is not correct or broken.

Class loader delegation

The loading of Java classes is performed by class loaders (CL), they are responsible for loading classes into the JVM. Simple applications can use the Java platform’s built-in class loading facility to load their classes, more complex applications tend to define their own custom class loaders.

The class loaders in Java are organized in a tree. By request a class loader determines if the class has already been loaded in the past, looking up in its own cache. If the class is present in the cache the CL returns the class, if not, it delegates the request to the parent. If the parent is not set (is Null) or can not load the class and throws a ClassNotFoundException the classloader tries to load the class itself and searches its own path for the class file. If the class can be loaded it is returned, otherwise a ClassNotFoundException is thrown. The cache lookup goes on recursively from child to parent, until the tree root is reached or a class is found in cache. If the root is reached the class loaders try to load the class and unfold the recursion from parent to child. Summarizing that we have following order:

• Cache
• Parent
• Self

This mechanism ensures that classes tending to be loaded by class loaders nearest to the root. Remember, that parent class loader is always has the opportunity to load a class first. It is important to ensure that core Java classes are loaded by the bootstrap loader, which guarantees that the correct versions of classes such as java.lang.Object are loaded. Furthermore it ensures, that one class loader sees only classes loaded by itself or its parent (or further ancestors) and it cannot see classes loaded by its children or siblings!

The picture illustrates the hierarchy of class loaders. Root loader is bootstrap class loader which has native implementation and cannot be instantiated by Java code.

It is followed by extension class loader, which is primary responsibility to load classes from the extension directories and provides ability to simply drop in new JVM extensions, without requiring modification to the user’s classpath. The system or application class loader responsible for loading classes from the path specified by the CLASSPATH environment variable. This class loader will be returned by the ClassLoader.getSystemClassLoader() method.

Phases of class loading

The are three phases of concrete class loading: physical loading, linking, and initializing.

1. In in first phase of physical loading required class file will be searched in specified classpaths. If the file is found it is read and the bytecode is loaded. This process gives a basic memory structure to the class object, such concepts like methods, fields, and other referenced classes are not known at this stage.
2. Linking can be broken down into three main stages, because it is complex phase:
   1. Bytecode verification through class loader, which executes a number of checks on the bytecodes.
   2. Class preparation. This stage prepares the necessary data structures that represent fields, methods and implemented interfaces that are defined within the class.
   3. Resolving of all the other classes referenced by a particular class. The classes can be referenced in a number of ways:
      • Superclasses
      • Interfaces
      • Field types
      • Types in method signatures
      • Types of local variables used in methods
3. During the initializing phase any static initializers contained within a class are executed so that, static fields are initialized to their default values.

It is interesting, that class loading can be performed in a lazy manner and therefore some parts of the class loading process may be done on first use of the class rather than at load time.

Exceptions

The biggest challenge in dealing with class-loading problems is that problems rarely manifest themselves during the class-loading process but rather during the usage of a class later on. In following shown two class loading related exceptions, with potential causes

• ClassNotFoundException
  • An archive, directory, or other source for the classes was not added to the class loader asked to load the class, or to its parent.
  • A class loader’s parent is not set correctly.
  • The wrong class loader is used to load the class in question.
• NoClassDefFoundError
  • An archive, directory, or other source for the classes was not added to the class loader asked to load the class, or to its parent.
  • A class loader’s parent is not set correctly.
  • Symbolic links in a class are unaccessible by the containing class’s class loader, such as a child class loader.

References:

• [2005,techreport] bibtex
  L. Shankar and S. Burns, "Demystifying class loading problems, Part 1: An introduction to class loading and debugging tools," 2005.
  @techreport{DW_2005_CLASSLOADING,
  author = {Lakshmi Shankar and Simon Burns},
  title = {Demystifying class loading problems, Part 1: An introduction to class loading and debugging tools},
  month = Nov, year = {2005},
  url = {http://www.ibm.com/developerworks/java/library/j-dclp1/index.html}
}

• [2004,techreport] bibtex
  A. Schaefer, "Inside Class Loaders: Debugging," 2004.
  @techreport{ONJAVA_2004_CLASSLOADING,
  author = {Andreas Schaefer},
  title = {Inside Class Loaders: Debugging},
  month = Jun, year = {2004},
  url = {http://www.onjava.com/pub/a/onjava/2004/06/30/classloader2.html}
}

• [2003,techreport] bibtex
  A. Schaefer, "Inside Class Loaders," 2003.
  @techreport{ONJAVA_2003_CLASSLOADING,
  author = {Andreas Schaefer},
  title = {Inside Class Loaders},
  month = Nov, year = {2003},
  url = {http://www.onjava.com/pub/a/onjava/2003/11/12/classloader.html}
}

Subject

It’s also dificult to define precisely subject of a website at the beginning, because nobody knows which topics are of our interest in e.g. two years. Neverthenless Simon and me defined some subjects for techjava.de, that will be covered in the nearest future. Simon summarized it here as:

TechJava is a project related to software engineering, especially enterprise system development in programming language Java. Beside this topic we are interested in topics: MDSD, SOA, requirement engineering, software methodologies and modeling

So stay with us!