Problems with jCifs authentication on oracle RDMS embedded jvm

I'm using jCifs 1.3.17 to connect and list files on remote windows share. Everything works fine on my local JRE(5,6,7), but the same code executed on oracle 11g database (11.2.0.3.0) crashes with following stack:

jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password. at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:546) at jcifs.smb.SmbTransport.send(SmbTransport.java) at jcifs.smb.SmbSession.sessionSetup(SmbSession.java) at jcifs.smb.SmbSession.send(SmbSession.java:218) at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176) at jcifs.smb.SmbFile.doConnect(SmbFile.java:911) at jcifs.smb.SmbFile.connect(SmbFile.java:954) at jcifs.smb.SmbFile.connect0(SmbFile.java:880) at jcifs.smb.SmbFile.exists(SmbFile.java) at pl.openlife.CifsConnect.listCIFSFiles(CifsConnect.java:49)

I found out, that user password lenght might cause the problem: 1. Windows env jdk1.5.0_22 -> works with long passwords 2. Oracle linux, RDMS embeded JVM -> works with short password only (8 characters) 3. Oracle linux, RDMS embeded JVM -> long password fails with error shown above.

Sample code:

NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(domain,
                   username,
                   password);

            SmbFile dir = new SmbFile(path,auth);

            if(!dir.exists()){
               // ABOVE CHECK FAILS
            }

I heard somewhere about problems with oracle embedded jvm and bugs in JCE, but this shouldn't be the case, as jcifs have its own implementation of algorithms such as RC4 or DES. Does anyone have a clue what can be the case? Is there a way to walk this around?

Solution

Unfortunately I didn't find any answer to the issue mentioned above. As a walkaround, I have used older version of jcifs (jcifs-1.2.25), which seems to work properly with oracle db embedded jvm.

UPDATE: I have imported jcifs lib again (1.3.17) and it is working like a charm. I ended up with conclusion, that the java library was not imported properly. Reimport (loadjava) with option "-force" and manual compilation of invalid objects solves the problem always, but (I cant't figure why) in my case it must be loaded in following order : 1. Load my program lib (will cause errors) 2. Load jcifs lib with force option 3. compile and resolve

It seems that oracle jvm is unpredictable :)