Weblogic datasource error: Locale not recognized after upgrading Oracle driver 9 -> 10

My company had developed a system that had been running in Sweden for years. Platform: Java, Weblogic, Oracle.

Recently, we decided to upgrade the Oracle thin driver from version 9 to 10.
Right after restart, we experienced a really odd problem: getConnection() calls failed with "Locale not recognized" error.

First I thought there is something to do with the database supported locale, partly because now we have to use orai18n.jar instead of orcs12.jar, but it was not the case.

This is the way to find out database locale settings:

select * from SYS.NLS_DATABASE_PARAMETERS

It was nothing Sweden specific, so there should be no problem with the database locale.

Then, I decided to debug the Oracle driver (credits to JadClipse ), and it turned out that Oracle 10 driver has something like this inside:

String s9 = CharacterSetMetaData.getNLSLanguage(Locale.getDefault());
if (s9==null) throw ....

...and this is where the exception caught comes from.

Ok, we are really close now.
Locale.getDefault() resulted locale se_SE.
(We are using different language resource files, and we set the default locale to this after reading the configs.)

But hey, shouldn't CharacterSetMetaData.getNLSLanguage support se_SE?
Actually, it shouldn't. Just check out the list of Supported Locales by Sun. It is sv_SE and not se_SE!! LOL!!

Fon status update

I've just read back my previous posts. I'm kind of surprised how enthusiastic I was about Fon about a year ago.

I've just made a screenshot about the current coverage in Budapest. You can see the development since my last post about it.

JCA: beware!

It has been quite a while since I post last time... I moved to a new apartment and it took all my time. Also, there was not too many interesting things to share, except for my experience with JCA (Java Connector Architecture):

I was involved in a project with the goal of improving one of the mission critical systems of a North European mobile telecom company. I was a great success, the upgrade went well, without major problems.

This system, had connection to 7 other systems. Each connection was implemented in a custom way. The protocols were CORBA, LDAP, JDBC and custom TCP/IP.

When I attended courses held by SUN (Developing Applications for the J2EE Platform and Architecting and Designing J2EE Applications), on both occasions, I was told that using JCA is the right way to implement connection to external systems, although we didn't write any connector due to the lack of time. The benefits I learned were:

1. Generalizing the custom codes
2. Container support (connection handling, monitoring, restart)
   
3. Industry standard

If you heard of these, and consider using JCA, I'd kindly encourage you to not to, or at least, think twice! Implementing JCA was a real pain for me. Here is why:

1. The specification is too complicated with many (I mean MANY!) interfaces.
2. I couldn't find an useful reference implementation
3. The concept of JCA is analogous with JDBC. This is what the container supports. However this is not what you need in most cases.
4. Class loader hell
5. The container support we could use is minimal
   

The 3rd one is the most important one: JCA is good when you can have many, same connections to the external system. This is the case when the container gives you support by pooling the connections. In our case, none of the connectors were like this. We had 1 connection per each of our external systems and we had to perform every operation on this single connection. Typically, this is the case when JCA gives you no help, just pain and waste of time: we ended up createing a JCA framework with ca. 50 classes, plus a generator to generate the connector implementations.

What did I mean by Class loader hell? Well, the problem is that the JCA resource adapters have their own class loader, so if you want to use classes during communication with the resource adapter, you have to package them outside of the connector and outside of your application too. Our dist EAR consist of 1 War, 7 Rars, 16 Jars build from our source, plus 14 3rd party Jars (and there are many connector specific Jars also inside of the Rars). So this is a big mess, but this was the only way we could cope with classloaders. Another possibility would have been serializing between JCA and the app...

If had the chance to start it again, I would have not used JCA at all. I liked the Java Connector Architecture concept very much, so if you have to create a connection fremework, the specification is a good thing to read to give you a few ideas, but then, you will be able to implement an own framework with much less work and complexity. Complexity is time and time is money.

I'd leave it to SAP, Siebel, and co. to create JCA resource adapters for their overproced products. For all others, think again!

Weblogic - Oracle DB transaction inconsistency

I was kind of surprised when I read this article about Oracle commititng transactions on connection close().

Currently we've are facing a problem with BEA Weblogic 8.1 sp4 connecting to Oracle DB. When the connection had problems, the first part of the user transaction got to the database, even without explicitely calling either commit(), or close().

Probably Weblogic implicitely calls close() which commits the user transactions. This nasty problem has been escalated to BEA support, I'll update you with the outcome.

FON free router giveaway

FON gives away free social routers for new members invited by existing Foneros. I was happy to invite one of my friends.

FON connectivity solved

I had trouble connection to my Fon social router using my notebook. Since this is my only wifi device and I can connect it to any other APs, I thought there was a problem with the router. In fact, it's the router that does not support the power saving feature of the Intel 3495ABG wifi chipset built into my notebook. Workaround can be found here and the latest Intel drivers here.

Retroweaver: develop with 1.5, deploy with 1.4

After 2 months of development with Java 5 and targeting Weblogic 9.2, it turned out that the customer wants to run our application on Weblogic 8.1 due to licensing issues.

Before geting too desperate, I've found something really impressive: Retroweawer.

This tool lets you develop with Java 5 and then create Java 1.4 compatible class files. It is an Ant task which translates Java 5 bytecode to 1.4.

Feel free to use the language features of Java 5 (generics, extended for loops, static imports, autoboxing/unboxing, varargs, enumerations, annotations), Retroweaver will support them all.

But pay attention! It's highly reccomended to enable reference verification. Otherwise, you may experience ugly runtime errors like we did: we had to tweak Echo2 to fully support file download with IE and I compiled it using Java 5. Without reference verification I could create a corrupt release for WL8.1. Everything went well until I opened the GUI: Echo2 did reset the session immediately and there was no error message, nowhere! It took me about 1 day to find what went wrong here: class file incompatibility.

As I said this all can be avoid using reference validation. To set up it correctly, you will need the runtime classpath specified in the classpath property in the Retroweaver task. In other words, you will have to list the JVM 1.4 runtime jars plus all of your allplication jars. The 'pathconvert' Ant task will be your best friend here. Seethe relevent parts of our build.xml below:


<taskdef name="retroweaver"
classname="net.sourceforge.retroweaver.ant.RetroWeaverTask">
<classpath>
<fileset dir="util/retroweaver-2.0Beta2"
includes="**/*.jar"/>
</classpath>
</taskdef>

<fileset id="libs_build" dir="libs">
<include name="**/*.jar"/>
</fileset>

<fileset id="java14runtime"
dir="${JDK14_HOME}">
<include name="**/*.jar"/> <!-- This could be
a bit more sophisticated -->
</fileset>

<path id="weave.classpath">
<fileset refid="java14runtime"/>
<pathelement location="build/classes-14"/>
<fileset refid="libs_build"/>
</path>

<target name="weave" depends="build">
<mkdir dir="build/classes-14"/>
<pathconvert pathsep=";"
property="weave.classpath.str"
refid="weave.classpath"/>
<echo message="weave
classpath=${weave.classpath.str}"/>
<retroweaver destdir="build/classes-14"
target="1.4"
classpath="${weave.classpath.str}">
<fileset dir="build/classes">
<include name="**/*.class"/>
</fileset>
</retroweaver>
</target>

Oracle 8 CLOB problem with Thin driver solved

Project: workflow system for major telecom company
Technologies: Java 5, Ajax(Echo2), Weblogic, jBpm, Hibernate
The problem: we have to connect to an Oracle 8.1.7 database and we have been experiencing all kind of weird stuff depending on the driver we were using.

Dispite Oracle states that all current drivers are compatible with (Oracle says: can talk to:) RDBMS 8.1.7, we had to face several incompatibility issues.

First we tried to use the latest 10g thin drivers. Everything went well until we tried to use a CLOB field to store special Hungarian text (árvíztűrőtükörfúrógép). We were unable to retrieve anything better that ?rv?zt?r?t?k?rf?r?g?p using JDBC, although TOAD showed the inserted values perfectly.

Then we switched to version 8 thin driver which proved to be the only Oracle JDBC thin driver capable of retrieving Hungarian chars from CLOB fields of a 8.1.7 database.

Things got worse when the text size increased, suddenly we started to receive this:
java.sql.SQLException: operation not allowed: streams type cannot be used in batching

It seems that the old JDBC driver does not support batch updates of Hibernate, therefore we disabled the batch update feature: hibernate.jdbc.batch_size=0

It didn't help. At the moment of DB connection closing, we got a deadlock... Awesome... What next?

Final attepmt: we switched to the OCI driver and it works well.

Conclusion: if you need to use CLOB fields with Oracle 8, your recommended choice is the OCI driver.

Fon is spreading in Budapest

Fon, the free Wifi community is spreading in my City. I've attached a map of downtown Budapest. The green spots are the free hotspots currently accessible by the Foneros. I'll update the map regularly so we can see the speed of the growing.

(Too bad that the Hungarian characters are not displayed correctly on the map. For example, in the text box you should see SZÉNA TÉR.)

First post

This is my first post here :)