We Keep Coding

java.lang.UnsatisfiedLinkError: cqjnilinuxproxy (Not found in java.library.path)

I have webservices deployed on WAS that use Clearquest jars to connect to Clearquest. At runtime, I get the following errors.
java.lang.Exception: Cannot parse the output since it has an error. Error = ReasonCode = conflictCRVAP0049E (internal-error): Cannot instantiate protocol provider: cqjnilinuxproxy (Not found in java.library.path)
...java.lang.reflect.InvocationTargetException:
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
at com.ibm.rational.stp.client.internal.core.ProtocolSubprovider.setProtocolProvider(ProtocolSubprovider.java:614)
... 57 more
Caused by: java.lang.UnsatisfiedLinkError: cqjnilinuxproxy (Not found in java.library.path)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1090)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:1054)
at java.lang.System.loadLibrary(System.java:510)
at com.rational.clearquest.cqjni.CQJNIBaseObj.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:202)
at com.ibm.rational.stp.client.internal.cqjni.CqJniProtocol.<init>(CqJniProtocol.java:2343)
... 62 more
I followed the technote https://www-304.ibm.com/support/docview.wss?uid=swg21515079 - "An exception occurs on 64-bit WebSphere servers when running reports from ClearQuest data sources that require the Java Native Interface (JNI).
As suggested, WAS 32-bit was installed instead on 64 bit. But the error still occurs. Can you please let me know where this library is or what is going wrong?
Thanks,
Aarthi

The ClearQuest libraries and jars need to be placed on the path so WebSphere can pick them up. Did you source cq_setup.csh prior to starting the WebSphere profile? You would need to source cq_setup.csh and then start the profile in the same shell.

HBase not starting after adding the jar file with Mapper/Reducer

I am trying to write a Mapper/Reducer for hbase and I added the jar. However after adding the jar file in lib directory, I cannot start hbase. I want to debug what is going wrong? How can I change the log level? Will it help?
Following is the exception:
java.lang.RuntimeException: Failed construction of Master: class org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster
at org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:143)
at org.apache.hadoop.hbase.LocalHBaseCluster.addMaster(LocalHBaseCluster.java:217)
at org.apache.hadoop.hbase.LocalHBaseCluster.(LocalHBaseCluster.java:153)
at org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:224)
at org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:139)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2290)
Caused by: java.lang.NoSuchMethodError: org.apache.hadoop.ipc.RPC.getProtocolProxy(Ljava/lang/Class;JLjava/net/InetSocketAddress;Lorg/apache/hadoop/security/UserGroupInformation;Lorg/apache/hadoop/conf/Configuration;Ljavax/net/SocketFactory;ILorg/apache/hadoop/io/retry/RetryPolicy;Ljava/util/concurrent/atomic/AtomicBoolean;)Lorg/apache/hadoop/ipc/ProtocolProxy;
at org.apache.hadoop.hdfs.NameNodeProxies.createNNProxyWithClientProtocol(NameNodeProxies.java:420)
at org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:316)
at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:178)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:665)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:601)
at org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:148)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2591)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:89)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2625)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2607)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:368)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296)
at org.apache.hadoop.hbase.util.FSUtils.getRootDir(FSUtils.java:1004)
at org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:562)
at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:364)
at org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.(HMasterCommandLine.java:307)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:139)
... 7 more

So it seems the error was due to mismatch of hadoop libraries in the lib directory of HBase(which was hadoop--2.5.1) against my actual Hadoop installation(hadoop--2.6.0). My jar was looking for classes which it was not finding in the older version of the hadoop libraries due to which it was failing. this answer made me realize the issue. After I copied all the hadoop-*-2.6.0 jars in the lib directory, HBase started as expected. The same is also mentioned in HBase-Hadoop compatibility documentation.

Jboss Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandle

When I tried jbosseap6.3 install as service. I got below error. Anyone have any idea on the below error. Any one shed light means it is very helpful for me.
java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:119)
at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338)
at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291)
at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:300)
at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:542)
at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
at org.jboss.as.logging.logmanager.ConfigurationPersistence.configure(ConfigurationPersistence.java:149)
at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:300)
at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:262)
at java.util.logging.LogManager$3.run(LogManager.java:399)
at java.util.logging.LogManager$3.run(LogManager.java:396)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
at java.util.logging.LogManager.access$800(LogManager.java:145)
at java.util.logging.LogManager$2.run(LogManager.java:345)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
at java.util.logging.LogManager.getLogManager(LogManager.java:378)
at org.jboss.modules.Main.main(Main.java:443)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:117)
... 18 more
Caused by: java.io.FileNotFoundException: C:\jboss-eap-6.3\standalone\log\server.log (The process cannot access the file because it is being used by another process)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at org.jboss.logmanager.handlers.FileHandler.setFile(FileHandler.java:154)
at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setFile(PeriodicRotatingFileHandler.java:105)
at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:192)
at org.jboss.logmanager.handlers.FileHandler.<init>(FileHandler.java:122)
at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.<init>(PeriodicRotatingFileHandler.java:73)
... 23 more
Shutdown JBossEAP6.3.0 service [2015-05-29 09:58:27]

Try to start jBoss server as administrator by pressing right mouse key, it will permit jboss to create all folders and files .

Right click the installation directory of Jboss EA (mine is C:\program files\EAP6.1, then Properties, Security tab. Given everyone permissions on this folder (all users you can see just give full control). This should then be able to create logs etc files within the required folder.
This is just a workaround though only works for local installs.

I had the same issue, it worked after running it on root, maybe you are running it without the proper rights.

I had resolved this issue by creating log directory in the
C:\jboss-eap-6.3\standalone\

it's a problem due to permissions, the solution that worked for me is that i removed the home directory of jboss wildfly from C:\programmes to C:\

Starting Wildfly/Jboss from the administrator cmd worked!!

You are most likely getting this error because you either have the log file open in a text editor or you're already running that instance of JBoss.

I got the same exception
Try changing the path from c to another destination, that solved my issue and I am able to start the server

ClassLoader classcastexception with activemq client

I have been struggling with this problem for a while now, decided to ask the community, hoping to get some hints/answers.
I am using tomcat 7.0.54 as my J2EE container which has a WAR deployed with dependency on activemq-all.
Along with the above, I'm also placing a jar in the classpath to register a listener programmatically, by implementing the ServletContainerInitializer interface. This initializes a simple implementation of an active mq client, JvmMessageProducerImpl (I have activemq-client as a dependency in the pom).
With the above setup, when i try to start tomcat, i get the below exception. It seems that instead of loading the classes independently, the listener which is called when the web application starts, is finding an existing instance of TcpTransportFactory and throwing the ClassCastException. I have read the classloader manual for tomcat multiple times, and my understanding is that each of the war files should have independent Class loaders - but dont completely understand why the exception is being thrown?
javax.jms.JMSException: Could not create Transport. Reason: java.io.IOException: Transport scheme NOT recognized: [tcp]
at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:317)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:330)
at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:251)
at com.monitoreverywhere.jvmmon.mq.JvmMessageProducerImpl.setup(JvmMessageProducerImpl.java:66)
at com.monitoreverywhere.jvmmon.mq.JvmMessageProducerImpl$Runner.run(JvmMessageProducerImpl.java:163)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.io.IOException: Transport scheme NOT recognized: [tcp]
at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:181)
at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:63)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:315)
... 5 more
Caused by: java.lang.ClassCastException: org.apache.activemq.transport.tcp.TcpTransportFactory cannot be cast to org.apache.activemq.transport.TransportFactory
at org.apache.activemq.transport.TransportFactory.findTransportFactory(TransportFactory.java:178)
... 7 more

Why would Java classloading fail on Linux, but succeed on Windows?

I've got a Java web application (using Spring), deployed with Jetty. If I try to run it on a Windows machine everything works as expected, but if I try to run the same code on my Linux machine, it fails like this:
[normal startup output]
11:16:39.657 INFO [main] org.mortbay.jetty.servlet.ServletHandler$Context.log>(ServletHandler.java:1145) >16> Set web app root system property: 'webapp.root' = [/path/to/working/dir]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:151)
at org.mortbay.start.Main.start(Main.java:476)
at org.mortbay.start.Main.main(Main.java:94)
Caused by: java.lang.ExceptionInInitializerError
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:129)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:51)
at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.http.HttpServer.doStart(HttpServer.java:708)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.jetty.Server.main(Server.java:460)
... 7 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.springframework.util.SystemPropertyUtils.(SystemPropertyUtils.java:42)
... 14 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 18 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 24 more
[shutdown output]
I've run the app with java -verbose:class, and according to that output, org.apache.log4j.Category is loaded from the log4j JAR in my /WEB-INF/lib, just before the first exception is thrown.
Now, the Java versions on the two machines are slightly different. Both the machines have Sun's java, the Linux machine has 1.6.0_10, while the Windows machine has 1.6.0_08, or maybe 07 or 06, I can't remember the exact number right now, and don't have the machine at hand. But even though the minor versions of the Javas are slightly different, the code shouldn't break like this. Does anyone understand what's wrong here?

You must understand that a classloader can't see everything; they can only see what a parent classloader has loaded or what they have loaded themselves. So if you have two classloaders, say one for Jetty and another for your webapp, your webapp can see log4j (since the JAR is the WEB-INF/lib) but Jetty's classloader can't.
If you manage to make a class available to Jetty (for example something in the DB layer) which uses log4j but which ends up running in the context (and classloader) of Jetty, you will get an error.
To debug this, set a breakpoint in org.springframework.web.util.Log4jWebConfigurer.initLogging(). If you can, copy the source of this class into your project (don't forget to delete it afterwards) and add this line:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Have a look at the cl object in your debugger. That should give you some information who created it. My guess is that this is the classloader from Jetty.
[EDIT] Note that you get in a different mess if you have log4j in both classloaders: In this case, you will have two classes with the same name which create objects which are not assignment compatible! So make sure there is only a single instance of this jar or that instances of log4j will never be passed between the two contexts (which is usually not possible).

This seems like a classic classloader problem. It could be due to another web app being loaded first which also uses log4j but a version that is different to the one used by the app you are testing. The classloader uses the first version of the class it finds. The server class loading policy can usually be changed in the config files. Sorry I am a bit rusty on this but maybe it can point you in the correct direction.
Make sure there are no other installed apps on the web server,
Make sure the log4j being loaded is the correct version,
Make sure you don't have a log4j lurking somewhere in the classpath of the server.
HTH

You're using the same WAR on both machines? Have you checked if the WAR files are identical (no transfer errors occured)?

Some random things to consider:
(1) Check if there are any other versions of log4j floating around on the linux instance, outside of the web-app directories?
(2) Is apache commons logging being used at all? You might want to consider SLF4J instead?
(3) Did the JAR/WAR become corrupt in some way - was it FTP'ed in ASCII or Binary?
(4) Print out the classloader hierarchy in each case, just to see if there are any discrepancies?

Even though the original problem was solved for the asker, I'll point out that a common source of problems when running the same code on Windows vs Linux (or Unix) is case-sensitivity issues. Windows ignores case while Linux or Unix is case-sensitive. This has bitten me more than once.
So if you specify a jar or directory on the classpath, but it isn't the right case then it will fail on Linux but succeed on Windows. This can also be the source of FileNotFoundExceptions.

Had the same problem and found an easy solution/workaround:
In Eclipse in Preferences > Java > Installed JREs, select the JRE > Edit and Add External JARs... and browse to your log4j.jar.
The other workaround is to add log4j.jar to every launch definition in Classpath tab.