Showing posts with label Java. Show all posts
Showing posts with label Java. Show all posts

Friday, June 19, 2009

Oracle BPEL and Weblogic and Java - JAR Hell

" JAR hell is a term used to describe all the various ways in which the classloading process can end up not working. "

- JAR Hell ( Wikipedia )

Avijeet , Raghu and myself - we are working on a challenging customer engagement and the environment has an Oracle BPEL 10.1.3.4 Server running off an Weblogic 9.2 Server. We recently encountered a scenario where we had to have a Java Client call a BPEL process deployed in this environment.

We used to regular boiler-plate Java BPEL Client code that you can get in the documentation, blogs, etc.

You can find a good example on Charles Piazza's SOA Blog.

However, to our chagrin, we noticed that the code always returned an opaque error :-

Exception in thread "main" java.lang.Exception:
Failed to create "ejb/collaxa/system/FinderBean" bean; exception reported is: "javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException:
error during JRMP connection establishment; nested exception is:
java.io.EOFException]
at weblogic.jrmp.Context.lookup(Context.java:189)
at weblogic.jrmp.Context.lookup(Context.java:195)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.oracle.bpel.client.util.BeanRegistry.lookupFinderBean(BeanRegistry.java:337)
at com.oracle.bpel.client.Locator.getFinder(Locator.java:956)
at com.oracle.bpel.client.Locator.listInstances(Locator.java:585)
at com.oracle.bpel.client.Locator.listInstances(Locator.java:554)

We pciked our brains on this for almost two days - until, suddenly, it hit us !

It was a classic case of JAR hell.

I had included all the JAR libraries of Oracle BPEL 10.1.3.4 and Weblogic 9.2 - for some strange reason, a few libraries in these two sets didn't like each other and this disgust resulted in the opaque "bean" exception.

Avijeet pointed this out & we both painstakingly removed the Weblogic Jar's one-by-one, until we noticed that we only required two sets of JARs to run the Java Class :-
  1. All the Oracle BPEL 10.1.3.4 Libraries.
  2. Only the weblogic.jar from Weblogic 9.2
Cool ! So, now it works and we can celebrate another victory against JAR hell !

Moral of the storey : Be very very careful with the JARs you use !


Sunday, February 22, 2009

Recursive Java Decompiler by Adarsh

" Often we encounter situations where the only solution to a certain Java problem is to decompile the contents of an entire JAR file, edit the resulting the source, rebuild and repackage before using. "


I found myself in this situation today & was struggling with CAVAJ and JAD to recursively generate Java classes present in an EAR file. I initially tried my hand at writing my own DOS Script to do this, but soon found that it takes a lot of time, patience & effort to write a script that does what I need. And time, unfortuantely, is in very limited supply today !

I Googled around looking for solutions & landed on this post by Adarsh. The Recursive Decompiler provided by Adarsh works like a charm *& saved a lot of time !

Thanks a lot Adarsh !

Monday, January 19, 2009

FlashBack to JDeveloper 10.1.2.2.0

" I want to migrate my application code base from JDeveloper 10.1.3 to 10.1.2 "

One of my colleagues recently faced this problem of moving the source code of a J2EE Application from Jdeveloper 10.1.3 to JDeveloper 10.1.2.

We faced a few issues during the process & here's a partial list of the issues we faced :-

1. Platform Migration Issues

JDeveloper 10.1.2.x makes use of JDK 1.4, whereas JDeveloper 10.1.3.x makes use of JDK 1.5. Hence, the move involves changing Java code to ensure that the code is stripped of all the useful features we are used to in JDK 1.5. E.g: contains() method of java.lang.String, etc.

2. “Error (n, m): identifier OracleJspRuntime not found”

We noticed that we had to manually add the JSP Runtime Library to the new Project in jDeveloper 10.1.2.

Please see one of my previous posts for more information about this problem.

3. Error: JSP files must reside in the server root directory or a subdirectory

We noticed that we had to manually change the HTML Root Directory to the new Project in jDeveloper 10.1.2.

Please see one of my previous posts for more information about this problem.

4. Change XSD references to DTDs

The JDeveloper 10.1.2.x does not recognize references to XSDs in web.xml & other configuration files. Hence, we had to manually change these references to DTDs.

Well, we managed to backport the application after resolving these problems. I would like to hear if there are any other similar experiences.

Thursday, October 23, 2008

“Error (n, m): identifier OracleJspRuntime not found”
- Jdeveloper Error.

You might have noticed this error sometimes in your Project.

The solution to this error is simple – you just need to add Jdeveloper’s “JSP Runtime” standanrd library to your Project Classpath – here are the steps to do it in Jdeveloper 10.1.3 : -

1. Right click on the Project & select the “Project Properties” option.
2. You can see the “Project Properties window.
3. Select the “Libraries” option. You can see the various configuration options for Project Libraries.
4. Click on the “Add Library” button. You can see the “Add Library” window.
5. Select “JSP Runtime” from the list of libraries & click on the “Ok” button.
6. “Make” / “Rebuild” your project.
7. You can see that you no longer see this error.


Thanks once again to the people who have discussed this at Oracle Technology Network Forums & various Bloggers who have spoken about it.

I am just posting this in my Blog for my reference.

JDeveloper JSP files must reside in the server root directory or a subdirectory

“Error: JSP files must reside in the server root directory or a subdirectory”

- Jdeveloper Error

How often have you struggled to specify a different folder for your JSPs, instead of JDeveloper’s default folder “public_html”?

I struggled with this option today – I inherited an application source code that I had to analyze & look our for ways to improve readability of the code. The application source code had been developed without an IDE (!), using our favorite ANT as the build tool.

I easily imported this code into Jdeveloper 10.1.3 (using NEW -> Project from Source Code). However, I noticed that I frequently hit the error mentioned above.

After Googling a bit, I stumbled upon a few OTN forum posts. I found out that the solution is rather simple.

1. Click on the “Tools” option in the Jdeveloper Menu.
2. Select the “Project Properties” option from the drop down.
You can see the “Project Properties” Window.
3. Click on the “+” in the “Web Application” section to expand the options.
4. You can see the “HTML Root Directory” option.
5. Specify the Root Directory of your JSP Pages here & click on the Ok button.
6. “Make” or “ReBuild” your project now.
7. You can notice that you no longer see this error.


The supplied JDeveloper help pages are slightly confusing – they don not mention that the “HTML Root Directory” option is present under the “Web Application” section.

Monday, March 17, 2008

Appending zeros in front of a number

I recently helped a colleague who had this simple requirement - to append zeros in front of a Number in a Java Method.

The purpose of the Method was to scan numbers between 1 and 999 and ensure that every number has three digits - the ones that have only two digits are appended by zeros.

The problem has multiple solutions & we were looking for the simplest possible solution. We tried a lot of solutions, starting with a simple for loop that counted the number of digits and appended zeros in front of it. We also looked at the Java API to see if a solution is already present.

However, we finalized two solutions that were very simple & elegant :-

Solution #1 ( JDK 1.5 onwards )

String.format("%03d", 1);
String.format("%03d", 10);
String.format("%03d", 100);


Solution #2 ( pre - JDK 1.5 )

NumberFormat objNumberFormat = new DecimalFormat("000");
objNumberFormat .format(Integer.parseInt( "1"));
objNumberFormat .format(Integer.parseInt( "10"));
objNumberFormat .format(Integer.parseInt( "100"));

We used Solution #2 to make the code reusable between JDK versions.