Call javap for rescue

Are you struck on a system with no java doc, Java IDE and internet and have to develop java applications. I encountered the same situation today. I wanted to check out the API methods offered by standard java libraries, but was struck. Finally, javap came to my rescue.

The command javap is class disassembler that lists all methods offered by a Java Class.



Getting idl2java Ant Task up and running

This blog is about using idl2java Ant task to generate Java artifacts from CORBA IDL file. The idl2java Ant task is provided by OpenORB, an open source CORBA implementation.

Any CORBA project starts with a idl file that describes the interface or service. Then, we use a tool to generate language specific client and server artifacts. The tool can be a command line executable or a Ant task.

The following idl file represents a simple attendance service.

module tracker {

	interface attendance {
		long addEmployee(in string empName);

		string removeEmployee(in long empId);

		void enterEmp(in long empId, in string empName);

		string empReport(in long empId);



The Ant Task idl2java is contained in openorb_orb_tools-<version>.jar. So, i add the jar to the Apache Ant Classpath. The task defination class is org.openorb.compiler.taskdefs.Idl2Java. I add the task defination.

The Ant build file is a very simple one. It invokes the idl2java task with two attributes, one points to the directory which contains the idl file and another points to the directory where the generated source files are dumped.

	<property name="idlDir" value="idl">
	<property name="srcDir" value="src">
	<target name="idl2java_task">
		<idl2java srcdir="${idlDir}" destdir="${srcDir}" verbose="false">

The Ant task idl2java has extensive set of options available. Check the documentation for more details.

Execute the Ant task and the build fails with the following error.

Buildfile: C:\java\myProjWorkSpace001\CORBAProj\build.xml


java.lang.NoClassDefFoundError: org/openorb/util/launcher/CompoundClassLoader
Total time: 188 milliseconds

As per error message, a class is missing. The documentation does not mention of any additional jar that needs to be added. I decided to check more on this missing class in additional jars that accompany the OpenORB distribution. But, none of them have it. Then, i checked out in website and found that the jar tmporb-tools-1.0-DEAD.jar had the class. The website provided a maven link for the jar, but i got 404 error. Searched in Google and found a maven repository which had it.

I added this jar to the Ant Classpath and executed the build script again. The ant task executed successfully and the Java artifacts coresponding to the idl are generated.

C:\java\myProjWorkSpace001\CORBAProj\src>cd tracker
C:\java\myProjWorkSpace001\CORBAProj\src\tracker>ls -ltr
total 22
a-----      3444 26-Nov-109 00:33
a-----       531 26-Nov-109 00:33
a-----      1809 26-Nov-109 00:33
a-----      7360 26-Nov-109 00:33
a-----      3359 26-Nov-109 00:33
a-----      1244 26-Nov-109 00:33
a-----       222 26-Nov-109 00:33

Next, to move ahead with implementation.🙂

Reblog this post [with Zemanta]

Process Explorer – Tool which provides Unix/Linux lsof command functionality for Windows

lsof command available in Unix and Linux operating system provides insight to running program. As explained in previous blog, the command is helpful to find the list of jars loaded by a Java application.

To do the same on Windows operating system, use the Process Explorer program available at

Start the Process Explorer, select the process which you want to analyze and enter CTRL + L. This brings up a lower pane that displays all system resources accessed by the process including files, threads, directories, port, etc. Filter the type column and you will be able to find all currently open files used by the application.

The following image displays the list of jar files accessed by Eclipse IDE.


Reblog this post [with Zemanta]

lsof and Unclosed file handlers

After checking out a blog entry about analyzing Classpath of a running Java program by Thilina Mahesh Buddhika, i decided to try the command on the Java Web server used at my organization. To my surprise, i was able to find unclosed file handlers in the application hosted on the Web server.


The command lsof -p lists all open sockets, files and pipes. By analyzing the output of the command, i was able to check all the files opened by the application and able to reason why it was open by going through the application code. This also helped me in fixing unclosed file handlers.

Try out the command and try figuring out why the files are referred to. This gives an insight to functioning of the application.

Check out the usage of the command @ following link

Reblog this post [with Zemanta]

Generating the DDL(Create and DROP) Statements of JPA Entities in EclipseLink

This blog is about generating the DDL Statements (CREATE and DROP DDL)  for the entities managed by the JPA. The JPA implementation used here is EclipseLink.

I have used the following Person class to be managed as Entity.

package com.entities;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

public class Person {

    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    int id;
    String fName;
    String lName;
    int age;

   //the setter, getter, methods for each of the attributes, toString,   

   //hashCode,  equals and default constructor are not shown here.

The persistence.xml file is as follows.

<?xml version="1.0" encoding="UTF-8"?>
<persistence:persistence version="1.0"
	xmlns:persistence="" xmlns:xsi=""
	xsi:schemaLocation=" ../../persistence_1_0.xsd ">
<persistence:persistence-unit name="simplePersistenceUnit">
<persistence:property name="eclipselink.jdbc.driver" value="com.mysql.jdbc.Driver"/>
<persistence:property name="eclipselink.jdbc.url" value="jdbc:mysql://localhost:3306/default"/>
<persistence:property name="eclipselink.jdbc.user" value="root"/>
<persistence:property name="eclipselink.jdbc.password" value="developer"/>

The persistence.xml contains information about the database.

The DDL generation information is provided to the persistence manager via a java.util.Map object.

package com.test;

import java.util.HashMap;
import java.util.Map;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

import org.eclipse.persistence.config.PersistenceUnitProperties;

import org.junit.Before;
import org.junit.Test;

public class TestExampleJPA {

	EntityManager em;

	public void testDDLGeneration() {
		Map<String, String> persistProperties = new HashMap<String, String>();
		persistProperties.put(PersistenceUnitProperties.DDL_GENERATION, "create-tables");
		persistProperties.put(PersistenceUnitProperties.DDL_GENERATION_MODE, "sql-script");
		persistProperties.put(PersistenceUnitProperties.APP_LOCATION, "C:\MyFolder\temp");
		EntityManagerFactory emf = Persistence.createEntityManagerFactory( "simplePersistenceUnit", persistProperties);
		em = emf.createEntityManager();

I have specified the database information in the persistence.xml file and DDL generation information into a Map object and providing it at runtime when creating the EntityManagerFactory object. Both the information can be provided fully either as part of  persistence.xml or Map object. I have combined both approaches for providing configuration information to JPA.

On executing the above test case the following sql files which contains the DDL for CREATE and DROP are created in C:\MyFolder\temp folder.



SocialTwist Tell-a-Friend

Reblog this post [with Zemanta]

WebService Client Target NameSpace clash

When handling multiple web services, you may have encountered scenarios where two web services declare schema definition under same namespace. Having multiple elements defined under same name space is not a problem. But, defining a same element with different structure under same namespace but in different web service can create problem.

This situation can happen when there is no global repository for the schema definitions in a company. I will explain the situation in more detail.

Consider a company XYZ with web address The company has two enterprise applications A and B. The application A decides to expose business function as web services. Two different teams 1 and 2 in application A are working on building the web service.

Both the team use the same target namespace

Team 1 builds an web service WS-1. They create a element NewOperation.

The schema of the element NewOperation and part of the wsdl definition is listed below

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="" xmlns:tns="" xmlns:wsdl="" xmlns:xsd="" name="NewWSDLFile" targetNamespace="">
    <xsd:schema targetNamespace="">
      <xsd:element name="NewOperation">
            <xsd:element name="in" type="xsd:string"/>

Team 2 also builds an web service WS-2. They also create a element NewOperation.

The schema of the element NewOperation and part of the wsdl definition is listed below

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="" xmlns:tns="" xmlns:wsdl="" xmlns:xsd="" name="NewWSDLFile" targetNamespace="">
    <xsd:schema targetNamespace="">
      <xsd:element name="NewOperation">
              <xsd:element name="in" type="xsd:string" />
              <xsd:element name="in_1" type="xsd:string"></xsd:element>

As you can see both the elements have the same name, but have different structure which is an not a good design. Since, both the team do not interact with other, they have failed to identify the flaw. Both, the team build server implementation of their web service and deploy each as EAR independent of the other. Both the teams do not face any issue, since both the server implementations are deployed independently.

Now, team in application B decides to use the web services provided by application A. They build client implementations for both the web services provided by A using standard build tools (clientgen from Weblogic). The build tools usually generate the java files (in a jar) binding the schema elements to classes created in the reverse namespace package (i.e., They put the client jars of both the web service in the same classpath of the application B.

When they try to use the operations provided by the web service, they face exception related to serialization or deserialization whenever an operation involving the element NewOperation is involved. The exception can happen in either the WS-1 or WS-2 web service. This is because, a wrong class is used in the web service. As per java classpath rule, whenever NewOperation class needs to be loaded it finds only one version of the class depending on which client jar appears first. The other NewOperation class is never found by the application.

In order to resolve the issue, the team A needs to move the definition of the element NewOperation in one of the web service to a different target namespace. But this is a costly option, since WS-1 and WS-2 are already implemented and will require changes in the server implementation and also for all the clients using the web service.

The other option is for the client to use options provided in the build tools to generate class binding the schema definition in different package other than that generated by default for one of the web service.

This can done in Weblogic tool clientgen by adding the option typePackageName. Note the additional attribute typePackageName in the ant build script.

<clientgen wsdl=""

Also the same can be done in Eclipse by checking the “Define custom mapping for namespace to package” option and defining the custom mapping when generating the client implementation of the web service.

This avoids the clash as the client implementations are generated under different package.

This problem needs to be avoided in first place when creating the web service. Each company needs to have a central repository where all the schema definitions are available to avoid duplication of element name under same target namespace.

Reblog this post [with Zemanta]