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.

Kafka Connect java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;

I am trying to setup kafka-connect-cassandra on an AWS instance.
I have setup plugin.path in connect-avro-distributed.properties file:
plugin.path=/home/ubuntu/kafka_2.11-1.0.0/plugins
And I have kafka-connect-cassandra-1.0.0-1.0.0-all.jar in:
/home/ubuntu/kafka_2.11-1.0.0/plugins/lib
This is the traceback:
[2018-02-18 10:28:33,268] INFO Kafka Connect distributed worker initializing ... (org.apache.kafka.connect.cli.ConnectDistributed:60)
[2018-02-18 10:28:33,278] INFO WorkerInfo values:
jvm.args = -Xmx256M, -XX:+UseG1GC, -XX:MaxGCPauseMillis=20, -XX:InitiatingHeapOccupancyPercent=35, -XX:+ExplicitGCInvokesConcurrent, -Djava.awt.headless=true, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -Dkafka.logs.dir=/var/log/kafka, -Dlog4j.configuration=file:/etc/kafka/connect-log4j.properties
jvm.spec = Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM, 1.8.0_151, 25.151-b12
jvm.classpath = /home/ubuntu/kafka_2.11-1.0.0/plugins:/usr/share/java/kafka/jackson-jaxrs-json-provider-2.9.1.jar:/usr/share/java/kafka/paranamer-2.7.jar:/usr/share/java/kafka/rocksdbjni-5.7.3.jar:/usr/share/java/kafka/jackson-jaxrs-base-2.9.1.jar:/usr/share/java/kafka/jetty-servlets-9.2.22.v20170606.jar:/usr/share/java/kafka/kafka-clients-1.0.0-cp1.jar:/usr/share/java/kafka/xz-1.5.jar:/usr/share/java/kafka/commons-lang3-3.1.jar:/usr/share/java/kafka/jetty-security-9.2.22.v20170606.jar:/usr/share/java/kafka/httpclient-4.5.2.jar:/usr/share/java/kafka/jackson-core-asl-1.9.13.jar:/usr/share/java/kafka/connect-json-1.0.0-cp1.jar:/usr/share/java/kafka/connect-runtime-1.0.0-cp1.jar:/usr/share/java/kafka/jersey-container-servlet-2.25.1.jar:/usr/share/java/kafka/commons-collections-3.2.1.jar:/usr/share/java/kafka/connect-transforms-1.0.0-cp1.jar:/usr/share/java/kafka/jersey-common-2.25.1.jar:/usr/share/java/kafka/zookeeper-3.4.10.jar:/usr/share/java/kafka/scala-library-2.11.11.jar:/usr/share/java/kafka/jackson-core-2.9.1.jar:/usr/share/java/kafka/argparse4j-0.7.0.jar:/usr/share/java/kafka/maven-artifact-3.5.0.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1-test-sources.jar:/usr/share/java/kafka/commons-codec-1.9.jar:/usr/share/java/kafka/kafka-connect-cassandra-1.0.0-1.0.0-all.jar:/usr/share/java/kafka/httpcore-4.4.4.jar:/usr/share/java/kafka/hk2-utils-2.5.0-b32.jar:/usr/share/java/kafka/connect-api-1.0.0-cp1.jar:/usr/share/java/kafka/javassist-3.21.0-GA.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1-sources.jar:/usr/share/java/kafka/support-metrics-client-4.0.0.jar:/usr/share/java/kafka/commons-compress-1.8.1.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1-scaladoc.jar:/usr/share/java/kafka/javax.servlet-api-3.1.0.jar:/usr/share/java/kafka/jersey-media-jaxb-2.25.1.jar:/usr/share/java/kafka/kafka-streams-1.0.0-cp1.jar:/usr/share/java/kafka/zkclient-0.10.jar:/usr/share/java/kafka/hk2-locator-2.5.0-b32.jar:/usr/share/java/kafka/slf4j-api-1.7.25.jar:/usr/share/java/kafka/support-metrics-common-4.0.0.jar:/usr/share/java/kafka/kafka.jar:/usr/share/java/kafka/jersey-server-2.25.1.jar:/usr/share/java/kafka/jackson-module-jaxb-annotations-2.9.1.jar:/usr/share/java/kafka/jetty-io-9.2.22.v20170606.jar:/usr/share/java/kafka/kafka-log4j-appender-1.0.0-cp1.jar:/usr/share/java/kafka/avro-1.8.2.jar:/usr/share/java/kafka/jackson-annotations-2.9.1.jar:/usr/share/java/kafka/guava-20.0.jar:/usr/share/java/kafka/hk2-api-2.5.0-b32.jar:/usr/share/java/kafka/lz4-java-1.4.jar:/usr/share/java/kafka/reflections-0.9.11.jar:/usr/share/java/kafka/commons-digester-1.8.1.jar:/usr/share/java/kafka/slf4j-log4j12-1.7.25.jar:/usr/share/java/kafka/jersey-client-2.25.1.jar:/usr/share/java/kafka/commons-lang3-3.5.jar:/usr/share/java/kafka/jackson-mapper-asl-1.9.13.jar:/usr/share/java/kafka/javax.annotation-api-1.2.jar:/usr/share/java/kafka/snappy-java-1.1.4.jar:/usr/share/java/kafka/javax.inject-2.5.0-b32.jar:/usr/share/java/kafka/jackson-databind-2.9.1.jar:/usr/share/java/kafka/jetty-http-9.2.22.v20170606.jar:/usr/share/java/kafka/kafka-streams-examples-1.0.0-cp1.jar:/usr/share/java/kafka/plexus-utils-3.0.24.jar:/usr/share/java/kafka/metrics-core-2.2.0.jar:/usr/share/java/kafka/connect-file-1.0.0-cp1.jar:/usr/share/java/kafka/kafka-tools-1.0.0-cp1.jar:/usr/share/java/kafka/jersey-guava-2.25.1.jar:/usr/share/java/kafka/commons-logging-1.2.jar:/usr/share/java/kafka/jetty-server-9.2.22.v20170606.jar:/usr/share/java/kafka/validation-api-1.1.0.Final.jar:/usr/share/java/kafka/jetty-continuation-9.2.22.v20170606.jar:/usr/share/java/kafka/osgi-resource-locator-1.0.1.jar:/usr/share/java/kafka/httpmime-4.5.2.jar:/usr/share/java/kafka/log4j-1.2.17.jar:/usr/share/java/kafka/jopt-simple-5.0.4.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1-javadoc.jar:/usr/share/java/kafka/javax.ws.rs-api-2.0.1.jar:/usr/share/java/kafka/jersey-container-servlet-core-2.25.1.jar:/usr/share/java/kafka/jetty-servlet-9.2.22.v20170606.jar:/usr/share/java/kafka/jetty-util-9.2.22.v20170606.jar:/usr/share/java/kafka/commons-validator-1.4.1.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1.jar:/usr/share/java/kafka/javax.inject-1.jar:/usr/share/java/kafka/commons-beanutils-1.8.3.jar:/usr/share/java/kafka/javassist-3.20.0-GA.jar:/usr/share/java/kafka/aopalliance-repackaged-2.5.0-b32.jar:/usr/share/java/kafka/kafka_2.11-1.0.0-cp1-test.jar:/usr/share/java/confluent-common/zookeeper-3.4.10.jar:/usr/share/java/confluent-common/common-metrics-4.0.0.jar:/usr/share/java/confluent-common/build-tools-4.0.0.jar:/usr/share/java/confluent-common/zkclient-0.10.jar:/usr/share/java/confluent-common/slf4j-api-1.7.25.jar:/usr/share/java/confluent-common/common-utils-4.0.0.jar:/usr/share/java/confluent-common/netty-3.10.5.Final.jar:/usr/share/java/confluent-common/common-config-4.0.0.jar:/usr/share/java/confluent-common/jline-0.9.94.jar:/usr/share/java/confluent-common/log4j-1.2.17.jar:/usr/share/java/kafka-serde-tools/kafka-json-serializer-4.0.0.jar:/usr/share/java/kafka-serde-tools/paranamer-2.7.jar:/usr/share/java/kafka-serde-tools/xz-1.5.jar:/usr/share/java/kafka-serde-tools/jackson-core-asl-1.9.13.jar:/usr/share/java/kafka-serde-tools/jackson-core-2.9.1.jar:/usr/share/java/kafka-serde-tools/kafka-connect-avro-converter-4.0.0.jar:/usr/share/java/kafka-serde-tools/commons-compress-1.8.1.jar:/usr/share/java/kafka-serde-tools/avro-1.8.2.jar:/usr/share/java/kafka-serde-tools/jackson-annotations-2.9.1.jar:/usr/share/java/kafka-serde-tools/kafka-schema-registry-client-4.0.0.jar:/usr/share/java/kafka-serde-tools/kafka-avro-serializer-4.0.0.jar:/usr/share/java/kafka-serde-tools/jackson-mapper-asl-1.9.13.jar:/usr/share/java/kafka-serde-tools/jackson-databind-2.9.1.jar:/usr/share/java/kafka-serde-tools/snappy-java-1.1.1.3.jar:/usr/bin/../share/java/kafka/jackson-jaxrs-json-provider-2.9.1.jar:/usr/bin/../share/java/kafka/paranamer-2.7.jar:/usr/bin/../share/java/kafka/rocksdbjni-5.7.3.jar:/usr/bin/../share/java/kafka/jackson-jaxrs-base-2.9.1.jar:/usr/bin/../share/java/kafka/jetty-servlets-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/kafka-clients-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/xz-1.5.jar:/usr/bin/../share/java/kafka/commons-lang3-3.1.jar:/usr/bin/../share/java/kafka/jetty-security-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/httpclient-4.5.2.jar:/usr/bin/../share/java/kafka/jackson-core-asl-1.9.13.jar:/usr/bin/../share/java/kafka/connect-json-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/connect-runtime-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/jersey-container-servlet-2.25.1.jar:/usr/bin/../share/java/kafka/commons-collections-3.2.1.jar:/usr/bin/../share/java/kafka/connect-transforms-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/jersey-common-2.25.1.jar:/usr/bin/../share/java/kafka/zookeeper-3.4.10.jar:/usr/bin/../share/java/kafka/scala-library-2.11.11.jar:/usr/bin/../share/java/kafka/jackson-core-2.9.1.jar:/usr/bin/../share/java/kafka/argparse4j-0.7.0.jar:/usr/bin/../share/java/kafka/maven-artifact-3.5.0.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1-test-sources.jar:/usr/bin/../share/java/kafka/commons-codec-1.9.jar:/usr/bin/../share/java/kafka/kafka-connect-cassandra-1.0.0-1.0.0-all.jar:/usr/bin/../share/java/kafka/httpcore-4.4.4.jar:/usr/bin/../share/java/kafka/hk2-utils-2.5.0-b32.jar:/usr/bin/../share/java/kafka/connect-api-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/javassist-3.21.0-GA.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1-sources.jar:/usr/bin/../share/java/kafka/support-metrics-client-4.0.0.jar:/usr/bin/../share/java/kafka/commons-compress-1.8.1.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1-scaladoc.jar:/usr/bin/../share/java/kafka/javax.servlet-api-3.1.0.jar:/usr/bin/../share/java/kafka/jersey-media-jaxb-2.25.1.jar:/usr/bin/../share/java/kafka/kafka-streams-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/zkclient-0.10.jar:/usr/bin/../share/java/kafka/hk2-locator-2.5.0-b32.jar:/usr/bin/../share/java/kafka/slf4j-api-1.7.25.jar:/usr/bin/../share/java/kafka/support-metrics-common-4.0.0.jar:/usr/bin/../share/java/kafka/kafka.jar:/usr/bin/../share/java/kafka/jersey-server-2.25.1.jar:/usr/bin/../share/java/kafka/jackson-module-jaxb-annotations-2.9.1.jar:/usr/bin/../share/java/kafka/jetty-io-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/kafka-log4j-appender-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/avro-1.8.2.jar:/usr/bin/../share/java/kafka/jackson-annotations-2.9.1.jar:/usr/bin/../share/java/kafka/guava-20.0.jar:/usr/bin/../share/java/kafka/hk2-api-2.5.0-b32.jar:/usr/bin/../share/java/kafka/lz4-java-1.4.jar:/usr/bin/../share/java/kafka/reflections-0.9.11.jar:/usr/bin/../share/java/kafka/commons-digester-1.8.1.jar:/usr/bin/../share/java/kafka/slf4j-log4j12-1.7.25.jar:/usr/bin/../share/java/kafka/jersey-client-2.25.1.jar:/usr/bin/../share/java/kafka/commons-lang3-3.5.jar:/usr/bin/../share/java/kafka/jackson-mapper-asl-1.9.13.jar:/usr/bin/../share/java/kafka/javax.annotation-api-1.2.jar:/usr/bin/../share/java/kafka/snappy-java-1.1.4.jar:/usr/bin/../share/java/kafka/javax.inject-2.5.0-b32.jar:/usr/bin/../share/java/kafka/jackson-databind-2.9.1.jar:/usr/bin/../share/java/kafka/jetty-http-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/kafka-streams-examples-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/plexus-utils-3.0.24.jar:/usr/bin/../share/java/kafka/metrics-core-2.2.0.jar:/usr/bin/../share/java/kafka/connect-file-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/kafka-tools-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/jersey-guava-2.25.1.jar:/usr/bin/../share/java/kafka/commons-logging-1.2.jar:/usr/bin/../share/java/kafka/jetty-server-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/validation-api-1.1.0.Final.jar:/usr/bin/../share/java/kafka/jetty-continuation-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/osgi-resource-locator-1.0.1.jar:/usr/bin/../share/java/kafka/httpmime-4.5.2.jar:/usr/bin/../share/java/kafka/log4j-1.2.17.jar:/usr/bin/../share/java/kafka/jopt-simple-5.0.4.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1-javadoc.jar:/usr/bin/../share/java/kafka/javax.ws.rs-api-2.0.1.jar:/usr/bin/../share/java/kafka/jersey-container-servlet-core-2.25.1.jar:/usr/bin/../share/java/kafka/jetty-servlet-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/jetty-util-9.2.22.v20170606.jar:/usr/bin/../share/java/kafka/commons-validator-1.4.1.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1.jar:/usr/bin/../share/java/kafka/javax.inject-1.jar:/usr/bin/../share/java/kafka/commons-beanutils-1.8.3.jar:/usr/bin/../share/java/kafka/javassist-3.20.0-GA.jar:/usr/bin/../share/java/kafka/aopalliance-repackaged-2.5.0-b32.jar:/usr/bin/../share/java/kafka/kafka_2.11-1.0.0-cp1-test.jar:/usr/bin/../share/java/confluent-support-metrics/*:/usr/share/java/confluent-support-metrics/*
os.spec = Linux, amd64, 4.4.0-1049-aws
os.vcpus = 2
(org.apache.kafka.connect.runtime.WorkerInfo:71)
[2018-02-18 10:28:33,279] INFO Scanning for plugin classes. This might take a moment ... (org.apache.kafka.connect.cli.ConnectDistributed:69)
[2018-02-18 10:28:33,290] INFO Loading plugin from: /home/ubuntu/kafka_2.11-1.0.0/plugins/lib (org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader:179)
Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
at org.reflections.Reflections.<init>(Reflections.java:126)
at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanPluginPath(DelegatingClassLoader.java:258)
at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.scanUrlsAndAddPlugins(DelegatingClassLoader.java:201)
at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.registerPlugin(DelegatingClassLoader.java:193)
at org.apache.kafka.connect.runtime.isolation.DelegatingClassLoader.initLoaders(DelegatingClassLoader.java:153)
at org.apache.kafka.connect.runtime.isolation.Plugins.<init>(Plugins.java:47)
at org.apache.kafka.connect.cli.ConnectDistributed.main(ConnectDistributed.java:70)
The first entry in jvm.classpath is the location where I have kafka-connect-cassandra.jar, inside plugin/lib.
guava.jars:
These are the paths of guava jars. Where should I place the kafka-connect-cassandra.jar or should I just remove any of these jars?
/usr/share/java/kafka-connect-elasticsearch/guava-18.0.jar
/usr/share/java/kafka-connect-storage-common/guava-14.0.1.jar
/usr/share/java/kafka/guava-20.0.jar
/home/ubuntu/cassandra/apache-cassandra-3.11.1/lib/guava-18.0.jar
Kindly help me out.

The Connect framework currently carries guava-20.0.jar in order to use Reflections and be able to scan your plugin.path for Connect plugins.
Connect framework's dependencies are added to your CLASSPATH if you are starting Connect using one of its bin scripts: connect-distributed or connect-standalone.
However, somehow an older version of guava is residing first in your CLASSPATH (maybe because you've set the CLASSPATH to include such a dependency), and then Connect is unable to scan your plugin.path with a guava version < 20. That's what your exception indicates. That Connect can't scan the plugin.path with the version of guava it finds in your CLASSPATH.
Your plugin.path should contain your plugins, each on its own directory. For example, similarly to what you have above:
plugin.path=/home/ubuntu/connect with
/home/ubuntu/connect/kafka_2.11-1.0.0/ and
/home/ubuntu/connect/kafka-connect-cassandra-1.0.0-1.0.0-all.jar
The layout above is used to make the point that plugins should not contain other plugins according to your example, but it's not recommended to set your plugin.path to a user's home directory.

This is a classpath issue. Looks like maybe you have an incompatible version of guava in the classpath? If your plugin path isn't including this method in any of the jars it has, that's a connector packaging issue. If it is, then you probably have two versions hanging around. Double check that plugin path with a find command to inspect all jars for that class in the message as a first step. Ultimately, you'll need to figure out what version of the dependency the connector expects and get that version and only that version into the plugin path.

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 &

getting java library error in application

I have a web application that is deployed on WebSphere and that use one java library to generate files in excel format but I am getting the following error in WebSphere, but it will work fine with the TOMCAT server.
What can the problem be?
ERROR IS :-
Error 500: java.lang.LinkageError: LinkageError while defining class:
jxl.format.CellFormat Could not be defined due to: (jxl/format/CellFormat) bad major version at offset=6 This is often caused by having a class defined at multiple locations within the classloader hierarchy. Other potential causes include compiling against an older or newer version of the class that has an incompatible method signature. Dumping the current context classloader hierarchy: ==> indicates defining classloader ==>[0] com.ibm.ws.classloader.CompoundClassLoader#50c450c4 Local ClassPath: C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\classes;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\activation-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\axis.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\cglib-nodep-2.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-discovery-0.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-logging.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-net-2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\commons-net-ftp-2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\dom4j-1.6.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\iText-5.0.6.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jaxrpc.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jdom-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jettison-1.0.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\joda-time-1.6.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\json-rpc-1.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\jxl.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\mail-1.4.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\ojdbc14.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\quartz-all-1.5.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\saaj.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\scheduler-plugin-example.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\scheduler-plugin.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\servlet-api.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\sqljdbc.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\stax-1.2.0.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\stax-api-1.0.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\wsdl4j.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\wstx-asl-3.2.7.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xml-writer-0.2.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xom-1.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xpp3_min-1.1.4c.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xstream-1.3.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war\WEB-INF\lib\xstream-benchmark-1.3.1.jar;C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\yagneshNode01Cell\apptoolv2.ear\apptoolv2.war Delegation Mode: PARENT_FIRST [1] com.ibm.ws.classloader.JarClassLoader#738995212 Local Classpath: Delegation mode: PARENT_FIRST [2] com.ibm.ws.classloader.ProtectionClassLoader#60e060e0 [3] com.ibm.ws.bootstrap.ExtClassLoader#70567056 [4] org.eclipse.osgi.framework.adaptor.core.CDSBundleClassLoader#4e024e02 [5] sun.misc.Launcher$AppClassLoader#6b806b80 [6] sun.misc.Launcher$ExtClassLoader#3fe03fe ---Original exception--- java.lang.UnsupportedClassVersionError: (jxl/format/CellFormat) bad major version at offset=6 at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:222) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:526) at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:477) at .............

This is the problem:
Could not be defined due to: (jxl/format/CellFormat) bad major version at offset=6
You're using a JExcel library compiled for a version of Java that your application server does not support. You'll either need to recompile the library or move to a newer version of WebSphere Application Server.
(The product printed the same "defined at multiple locations" error with class loader dump for all LinkageError, regardless of whether that text is actually relevant, until around 6.1.0.21.)

Looks like you've got Andy Khan's JExcel library in the CLASSPATH twice. See if WebSphere ships with it. If it does, remove yours from the application WEB-INF/lib and see if that helps.

Solaris JMS Client connect to Weblogic 11g t3s security problem

When I try to connect Weblogic t3s protocol in Solaris Server, it shows this error:
java.lang.IllegalStateException: Not enough cryptography available to enable a cipher suite!
at com.certicom.tls.interfaceimpl.TLSSystem.resetCipherSuiteSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.setCertificateSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.net.ssl.SSLContext.<init>(Unknown Source)
at com.bea.sslplus.CerticomSSLContext.<init>(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor6.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at weblogic.security.utils.SSLSetup.getSSLDelegateInstance(SSLSetup.java:122)
at weblogic.security.utils.SSLContextWrapper.<init>(SSLContextWrapper.java:48)
at weblogic.security.utils.SSLContextWrapper.getInstance(SSLContextWrapper.java:43)
at weblogic.security.utils.SSLSetup.getSSLContext(SSLSetup.java:238)
at weblogic.security.SSL.SSLClientInfo.getSSLSocketFactory(SSLClientInfo.java:101)
at weblogic.socket.ChannelSSLSocketFactory.getSocketFactory(ChannelSSLSocketFactory.java:170)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:77)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:114)
at weblogic.socket.BaseAbstractMuxableSocket.createSocket(BaseAbstractMuxableSocket.java:133)
at weblogic.rjvm.t3.MuxableSocketT3.newSocketWithRetry(MuxableSocketT3.java:206)
at weblogic.rjvm.t3.MuxableSocketT3.connect(MuxableSocketT3.java:375)
at weblogic.rjvm.t3.ConnectionFactoryT3S.createConnection(ConnectionFactoryT3S.java:34)
at weblogic.rjvm.ConnectionManager.createConnection(ConnectionManager.java:1773)
at weblogic.rjvm.ConnectionManager.findOrCreateConnection(ConnectionManager.java:1416)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:437)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:315)
at weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal(RJVMManager.java:251)
at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:194)
at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer(RJVMFinder.java:238)
at weblogic.rjvm.RJVMFinder.findOrCreateInternal(RJVMFinder.java:200)
at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:170)
at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:153)
at weblogic.jndi.WLInitialContextFactoryDelegate$1.run(WLInitialContextFactoryDelegate.java:344)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:339)
at weblogic.jndi.Environment.getContext(Environment.java:315)
at weblogic.jndi.Environment.getContext(Environment.java:285)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:117)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
I have define the following parameters:
-Djava.protocol.handler.pkgs=weblogic.net -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreType=JKS -Dweblogic.security.CustomTrustKeyStoreFileName=keystore -Dweblogic.security.CustomTrustKeyStorePassPhrase=passphrase -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
How can I fix it? Same source and same parameters is working in Windows.
Thank You.

This solution comes a bit late in the day, but is meant for others having the same problem.
Apparently, the accepted solution of adding webserviceclient+ssl.jar to the classpath works, since the WebLogic Full Client - wlfullclient.jar has references to other JARs in its MANIFEST.MF file. Adding the webservices client JAR resolves the issue, since it appears to have the minimum set of classes required for correct operation of the client when using SSL/TLS. The error is usually encountered when copies of the wlfullclient.jar and wlcipher.jar are made in a different directory, and added to the classpath. The JVM then fails to load other dependent classes from JARs that are referenced from within the MANIFEST file.
The actual solution would be to add the wlfullclient.jar that is generated in the WL_HOME\server\lib directory, to the CLASSPATH. All other dependent JARs would then be picked up via the appropriate classloader, since the manifest references these via relative directory paths.

Are you using the same JVM vendor on both machines?
Most likely the CA used to generate the keystore is available on the Windows truststore but not available on Solaris, the assumption being the keystore was generated in Windows and the CA is not yet shipped with the JRE being used on Solaris. The differences are discussed here.
How to configure the truststore to add a CA

Finally, We got the solution.
Just add webserviceclient+ssl.jar to your classpath will solve the problem.
webserviceclient+ssl.jar not included in wlfullclient.jar.

Are you sure that you keystore file is picked up? Maybe try to use an absolute path when specifying the -Dweblogic.security.CustomTrustKeyStoreFileName option.
Also, are the classpath of the JMS client really identical in both environments?
Try to provide wlserver_10.3/server/lib/wlfullclient.jar (that you create by running the command java -jar wljarbuilder.jar) and wlserver_10.3/server/lib/wlcipher.jar (yeah, wlfullclient.jar is not that full!) on the classpath.

This has been simplified for 10.3.4 and above Weblogic.
Just add the wlthint3client.jar from the /server/lib directory to your client's Classpath
I've only confirmed this works for ejb communication but the docs state
This release supports the following:
Oracle WebLogic's T3/T3S protocol for Remote Method Invocation (RMI), including RMI over HTTP (HTTP tunneling). For more information on WebLogic T3 communication, see "Using WebLogic RMI with T3 Protocol" in Programming RMI for Oracle WebLogic Server.
Access to JMS, JMX, JNDI, and EJB resources available in WebLogic Server.
http://docs.oracle.com/cd/E17904_01/web.1111/e13717/wlthint3client.htm