A superb blog :-

http://idcmp.blogspot.com/2007/01/lack-of-decent-java-developers.html

The ejb-jar file must also contain, either by inclusion or by reference, the class files for all the classes and interfaces that each enterprise bean class and the home and component interfaces depend on, except J2EE and J2SE classes. This includes their superclasses and superinterfaces, dependent classes, and the classes and interfaces used as method parameters, results, and exceptions.

EJB 2.0 Specification 23.3

I have read & re-read the EJB Specification many times over in order to get a good insight, but I have now learnt that only experience can offer clear insights.

The blurb from the EJB 2.0 Specification - 23.3 mentions that the EJB JAR file must
contain the primary EJB Classes ( The Bean Class, Remote & Home Ineterfaces ), either by inclusion or by reference.

I did not pay much heed to the phrase "..inclusion or by reference". I just thought that it may not be really significant in the big scheme of things - I alaways assumed that such phrases are tossed between simple sentences to make them look more "legal".

However, that phrase "...inclusion or by reference" is very very important & I realized it only recently.

I got hold of an EJB EAR file that was packaged in a different manner :-














I always walked on the beaten track & was surprised to see that the classes & the Deployment Descriptrs ( DD ) don't share the same JAR File.

After discussions in Oracle Technology Forums & debates with some of my colleagues ( & of course, reading the EJB Specification late into the night ), I understood that it's perfectly normal to package it in different JAR Files. The WebLogic Application Server used a concept of APP-INF Folder in EAR files to dump some of the application's common libraries.

Well, the meat of the topic here is that at the time of deployment, the EJb classes should be available for the Container. The Container should be able to locate the classes in the application ClassPath. Hence, we can rewire the application classpath & informn the Container about the catucal location of the EJB Classes.

Again, reverting to the EJB Specification 2.0 ( 23.1 ) ,

The ejb-jar file format is the contract between the Bean Provider and the Application Assembler, and between the Application Assembler and the Deployer.

The same works for Servlets & web.xml.

I would defenitely request the authors of the EJB Speicification to keep the language simple ( as in the JavaMail or JMS Specifications ). It would help mid-level developers like myself to get more comfortable with EJBS. It would also motivate the newbies to step into the world of EJBs with more confidence.

Java's Garbage Collection is a very interesting topic & I have not yet explored the nuts & bolts. I am still reading articles by Bill Venners & co to understand the nuts & bolts.

Recently, I was asked by a newbie about Memory Leaks in Java. He had just stepped into the world of Java & wasn't sure about Garbage Collection & Memory Leaks in Java. He asked me if it was possible to show an instance of Memory Leak in Java.

The question has been adressed numerous time ever since the first Java Version rolled out. A lot of examples are availale on the net that show how to get a Memory Leak from Java.

I wrote this example on the fly & wanted to save it for posterity :-

import java.util.ArrayList;

public class MemoryLeakSimulator
{

public static void main(String[] args)

{
try

{

System.out.println(" MemoryLeakSimulator.main() :: Start :: Leak ");

ArrayList objHeapPigArrayList = new ArrayList();

ArrayList objHeapSinkArrayList = new ArrayList();

for(

long lCounter = 0;

lCounter <>

lCounter ++

)

{

objHeapSinkArrayList = new ArrayList();

objHeapPigArrayList.add(objHeapSinkArrayList);

}

System.out.println(" MemoryLeakSimulator.main() :: End :: Leak ");

}

catch (Throwable objThrowable)

{
objThrowable.printStackTrace(System.out);

}// end of the try block

}// end of main() method

}// end of MemoryLeakSimulator

There is nothing new or innovative in the code - Objects are created in the "Heap" memory of the JVM. The Garbage Collection tries to free the menmory used by "unreferencable" object. However, in this case, we are continously pumping objects to the ArrayList & at a critical time, you may notice this error :-

..................

...................

...................

[Full GC 60651K->60648K(65088K), 0.3803447 secs]

[Full GC 65087K->65086K(65088K), 0.4023478 secs]

[Full GC 65086K->65086K(65088K), 0.3938506 secs]

java.lang.OutOfMemoryError: Java heap space

That's the meat of it !

Also, every Memory Leak ( at least in 1.5 ) generates a hs_err_pid*.log file. It gives a lot of useful information.

I had a requirement - I needed to replace the application.xml file inside an EAR file without unpacking the EAR File. Well, ANT came to the rescue ( as sual ) - I used this piece of logic to get it working :-

< target name="modify_ear
>

< touch

file="${src.dir}/application.xml" />

<
ear
destfile="${src.dir}/${ear.name}.ear"

update="true"

appxml="${src.dir}/application.xml"

/>

< /target >

The key here was to "touch" the application.xml file sitting outside the EAR
file. The "touch" changes the TimeStamp of the File & hence, it gets updated
in the EAR File.

Well, it took a while to figure out this one.

I have been working on OC4J & TomCat for quite sometime & WebLogic was always a mystery. A piecie of the puzzle was the folder APP-INF that I used to find in may WAR & EAR Files.

I initially assumed that APP-INF was a J2EE standard - however, I was proved to be incorrect in a few minutes of Googling. APP-INF is not a J2EE standard, but rather a BEA extension to the standard.

The solution in OC4J is to rewire the classloasing using orion-application.xml :-

library path="../../applications/earname/APP-INF/lib"
library path="../../applications/earname/APP-INF/classes"

Thankfully, I was working with the latest OC4J 10.1.3.1.0 & it's Enterprise Manager offers a "Configure Classloading" option at the last step of application deployment. I lazily used this option instead of tweaking the orion-application.xml

Thanks to Olaf Heimburger for enlightening me ! :-

http://forums.oracle.com/forums/thread.jspa?messageID=1590796

http://blogs.oracle.com/olaf/2006/12/12#a65

A very interesting dicussion was on at the Java Forums - How many methods can be stuffed into a Java Class ?

One of the replies from Rene Chennault was that the Class File Specification limits this to 2^16. I was curious to know where this information was & I asked in the Thread. The reply was to check this link :-

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html

The "u2 methods_count;" is the key - u2 means 2 Bytes.

The complete Forum Thread is at this link :-

http://forum.java.sun.com/thread.jspa?threadID=5121112

I was looking for a good article that details the merits of a "Server" JVM vs "Client" JVM. I found a good article frome BEA :-

http://dev2dev.bea.com/pub/a/2004/02/jrockit.html

I found a neeat trick in one of the Forums to get a list of JAR files in a directory & its subdirectories in Windows. You need to type this command at the root folder: -

DIR /S/B *.JAR

You’ll see a list of JAR files under the folder & it’s subdirectories. This is very useful in setting the ClassPath – via the Command Line or using a Custom ClassLoader.

I have created this Blog as a bread crumb - to remember things that I may need at a very very short notice. I just thought it might be useful to others.