Skip to content

Archive

Author Archive

FirebirdPhoenix_Logo
Accessing a relational database system from Java is a basic step required for many applications. The JEE architecture defines a standard for gaining this access, calls Java Connector Architecture (JCA). This article is a short HOWTO of configuring JCA-compliant datasource to a Firebird 2.x RDBMs using JBoss AS 5.1.0 as example. This tutorial is based on a Windows installation, but can be easily ported to Linux, or other OS.

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

continue reading…

I found strange problem running wscompile (from Sun’s Java Web Service Developer Pack 1.6) inside Ganymede (Eclipse Version 3.4.1). The run of the wscompile Ant task produce a problem. The build script execution freezes on the wscompile task. It prints the following message on console but then nothing happens.

[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.

In a last weeks or month Simon and me have upgraded design (as you see) and the engine of Techjava journal. Also we started the Techwiki which is nearly completely integrated with the blog engine. Latest test are running and the whole integration will be available soon.

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.

It’s good to know, how Java class loading works, when you have to develop in Java. Basic understanding of class loading process helps every Java developer to deal with several ClassLoader related Exceptions.

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.

The class loader delegation model

 

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.

The phases of class loading

  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 Go to document
    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 Go to document
    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 Go to document
    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}
    }

Hi folks out there, I think it’s time to make clear that we are seriously begin to make something out of this site. The beginning is hard ever, so the is no other way as just to begin. At the moment there are two administrators of this site ( Simon and me) and two authors (Helge and Mariya). We have to deal with Java and Software Development at work or during the study. So why not start notify it here.

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!