Develop Reference

java.sql.SQLException: Problems with loading native library/missing methods: no ttJdbc181 in java.library.path

I am running TimesTen facing application in local (in eclipse IDE). URL and username and password seems to be fine. But I am getting below exception.
java.sql.SQLException: Problems with loading native library/missing methods: no ttJdbc181 in java.library.path
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:2012)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:296)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:152)
at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:319)
at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:212)
at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:736)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:668)
at org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:483)
at org.apache.tomcat.jdbc.pool.ConnectionPool.<init>(ConnectionPool.java:154)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.pCreatePool(DataSourceProxy.java:118)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:107)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.getPool(DataSourceProxy.java:214)
I checked the bin folder of TimsTen installation directory did not see ttJdbc181.dll file Instead I found ttJdbcCS.181 in the folder. I don't know why code is looking for ttjdbc181.dll file. I have tried adding ttjdbc8,9,10,11 to class path still same issue. Any help to resolve this issue will be appreciated.

Had same stack trace.
All I had to do is to add "jdbc:timesten:client:" to my connection string. It is driver and protocol as far as my understanding goes.
My connection string looks like follows:
jdbc:timesten:client:TTC_Server=127.0.0.1;TTC_Server_DSN=myDsn;UID=user;PWD=userpasswd;TCP_PORT=9999;
This was issue on Windows. Assume same would arise for Linux.
Also please ensure you have correct CLASSPATH, Lib, Include, Path environment variables.
Windows installer usually takes care of this. On Linux you have to run ttenv.sh script from directory of your installed instance, this will set env vars as required.

JRuby 9.0.5.0 cannot load compiled ruby files

Our application is a RoR app, and currently uses JRuby version 1.7.22, and JRE 8_65. Our app is an on-prem solution, so we use JRuby to host our application on JVM at the target, Windows Server 2012 R2 system. We compile our ruby code, using
jruby -S jrubyc
This takes the .rb file and compiles it to a .class file. In the original .rb, it loads in the class file, like so.
load __FILE__.sub(/\.rb$/, ".class")
This all works with JRuby 1.7.22
Now, we want to update JRuby to 9.0.5.0, but are experiencing some problems when it comes to deploying our application. Basically, that line of code above inside of the .rb file is not working anymore, and we get the error when trying to run a rake db:setup
rake aborted!
LoadError: C:/appname/app/models/app_attribute.class is not compiled Ruby; use java_import to load normal classes
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Great. So I replace load with java_import
rake aborted!
ArgumentError: not a valid Java identifier: C:/appname/app/models/app_attribute.class
uri:classloader:/jruby/java/core_ext/object.rb:43:in `block in java_import'
uri:classloader:/jruby/java/core_ext/object.rb:34:in `java_import'
C:/appname/app/models/app_attribute.rb:1:in `<top>'
C:/appname/db/seeds.rb:10:in `<top>'
C:/appname/db/seeds.rb:9:in `block in (root)'
Tasks: TOP => db:setup => db:seed
(See full trace by running task with --trace)
Still not working, no matter what I try. I looked at this post: https://github.com/jruby/jruby/issues/3018
I tried to pass the parameter
jruby -Xaot.loadClasses=true
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
jruby -Xproperties
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated. Is there something I missing? I am not fully adept in Java.
Thank you.

might be the same issue as https://github.com/jruby/jruby/issues/3651
which means you'll need to wait for 9.1 or use a snapshot http://ci.jruby.org/
since, the error is slightly different you should look into reproducing with snapshot and if it fails (might be Windows related) a step-by-step reproduction might speed-up getting the issue resolved.
jruby -Xaot.loadClasses=true
this is not needed with Warbler
But I get a warning saying that aot.LoadClasses is not recognized. EVEN THOUGH I see it in the properties when I type
hmm, could you reproduce this with an empty script and no JRUBY_OPTS ?
I have done A LOT of research on this, and have probably have looked at everything on the internet regarding this. Any input will be greatly appreciated.
you might want to try looking into the issue next time :) or considering getting some support
Is there something I missing? I am not fully adept in Java.
you shouldn't be missing anything - its not a Java issue ...

Use sqlite with Java on Raspberry pi

I have created small code of sqlite database in java.
Below is the code for connection with database,
Class.forName("org.sqlite.JDBC");
objConnection=DriverManager.getConnection("jdbc:sqlite:/etc/javaData/Test.db");
In this code the exception thrown in second line for getConnection(). I am trying this code on Raspberry pi. How to fix the exceptionrelated to this
Exception
SQLITE addDeviceInfo()-[SQLITE] SQL Exception occured. RetryCount:1 (MAX Retry: 2) ErrorCode: 27154 Exception Message: Error opening connection Stack Trace: java.sql.SQLException: Error opening connection
at org.sqlite.core.CoreConnection.open(CoreConnection.java:140)
at org.sqlite.core.CoreConnection.<init>(CoreConnection.java:66)
at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:21)
at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:23)
at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:45)
at org.sqlite.JDBC.createConnection(JDBC.java:114)
at org.sqlite.JDBC.connect(JDBC.java:88)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:215)
at kmbt.DCA.SQLite.DCASQLiteUtility.getSQliteConnection(DCASQLiteUtility.java:152)
at kmbt.DCA.SQLite.ManagedDeviceSetting.SQLite_ManagedDeviceSettingManager.addDeviceInfo(SQLite_ManagedDeviceSettingManager.java:981)
at kmbt.DCA.DCAChildProcessMng.InitManagedDeviceInfo(DCAChildProcessMng.java:5726)
at kmbt.DCA.DCAChildProcessMng.InitSQLite(DCAChildProcessMng.java:4387)
at kmbt.DCA.DCAChildProcessMng.start(DCAChildProcessMng.java:365)
at kmbt.DCA.DCAChildProcess.main(DCAChildProcess.java:23)
Caused by: java.lang.Exception: Error loading native library: /org/sqlite/native/Linux/arm/libsqlitejdbc.so
at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:243) at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:65)
at org.sqlite.core.NativeDB.load(NativeDB.java:53)
at org.sqlite.core.CoreConnection.open(CoreConnection.java:136)
... 14 more

Your code seems correct and the exception thrown seems don't have nothing to do with some library's problem.
The only thing that sound me a little bit strange, is that you put your database in /etc folder. First of all it is not very correct, because the /etc folder is used to store config file and not data. In addition to this, maybe there could be some kind of issue with r/w folder's permissions. Try to move your database to your home directory or to other any directory owned by your user and not from root.
Hope this will be usefull for you.
-- EDIT --
Ok, the problem is that you have downloaded the wrong library:
Error loading native library: /org/sqlite/native/Linux/arm/libsqlitejdbc.so
You have to use the ARM build of the sqlite library. Try to take a look at this:
Error opening connection SQLite on Raspberry pi
and this: Sqlite4java on Raspberry Pi

I also faced java.lang.Exception: Error loading native library: /org/sqlite/native/Linux/arm/libsqlitejdbc.so
Looking into sqlite-jdbc-3.8.6.jar I found that /org/sqlite/native/Linux/ contains no arm folder -> sqlite is not compiled for arm.
With these changes I've managed to build on the pi: https://bitbucket.org/kidmose/sqlite-jdbc/commits/cb7a7ef62c034938e8ecb737b148e5c80877c083
pi#raspberry ~/sqlite-jdbc $ export JAVA_HOME=/usr/lib/jvm/jdk-7-oracle-armhf/
pi#raspberry ~/sqlite-jdbc $ chmod 755 ./amalgamation_version.sh
pi#raspberry ~/sqlite-jdbc $ make
Replacing the old jar with the newly built one solved my problem.
All credit goes to: https://pidome.wordpress.com/2013/10/01/java-goes-hard-on-the-raspberry-pi-so-does-pidome/

Jruby Applets: (LoadError) no such file to load

I'm currently having real problems trying to get the gem Nokogiri to work in my applet. I have the jruby-complete-1.7.3 jar and have attempted to install gems using the normal install line:
java -jar jruby-compelete-1.7.3.jar -S gem install nokogiri
And also I have tried the Gem-In-A-Jar method. At first it works fine, and allows me to eval ruby code and store the data returned. My problem arises when I add in the line:
require 'nokogiri'
While that line works fine in the irb, when trying to access it from the applet I get the following error:
classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems.rb:396 warning: can't
canonicalize loaded names due to security restrictions; disabling
Message: (LoadError) no such file to load -- nokogiri
Stacktrace:
org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- nokogiri
at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1027)
at RUBY.require(classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36)
at RUBY.(root)(<script>:2)
I simply can't figure out why this exception is occuring. I've tried:
moving the gems manually into the "META-INF/jruby.home/lib/ruby/gems/shared" folder
I've added "require 'rubygems'" above the the nokogiri call.
Accessing the gems via the Gems-in-a-jar method: http://blog.nicksieger.com/articles/2009/01/10/jruby-1-1-6-gems-in-a-jar/
If anyone has an idea where I've gone wrong, or a solution to this issue, I'd greatly appreciate it.

RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)

I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.

Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html

It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734

If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!

If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.

I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).

Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.

I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &