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!!
Showing posts with label weblogic. Show all posts
Showing posts with label weblogic. Show all posts
2008-03-19
2007-01-15
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.
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.
2006-12-19
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>
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>
Subscribe to:
Posts (Atom)