X
PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 16 Sep 2010 01:34 PM by  anon
IDL Bridge - ELFCLASS64 error
 0 Replies
Sort:
You are not authorized to post a reply.
Author Messages

anon



New Member


Posts:
New Member


--
16 Sep 2010 01:34 PM
    I'm trying to deploy a Java Webapp that uses the Java-IDL Bridge onto a local test glassfish environement. Previously, we had it working on another server, but we were trying to upgrade to a better machine. The main difference is our previous machine used a 32-bit linux environment, where the new machine uses a 64-bit environment; also the old deployment used glassfish v2, and the new deployment is using glassfish v3. The main portion of the tool works fine; however, when trying to make an IDL call using the IDL Bridge classes, we were previously getting this message: [#|2010-09-16T13:12:07.015-0600|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|16 Sep 2010 13:12:07,013 [pool-5-thread-2] ERROR org.nsidc.ccaws.model.PlotPackageImpl - Error thrown by IDL code: java.lang.UnsatisfiedLinkError: com.idl.javaidl.JIDLPAL.nativeInitJPAL()V at com.idl.javaidl.JIDLPAL.nativeInitJPAL(Native Method) at com.idl.javaidl.JIDLPAL.(JIDLPAL.java:189) at com.idl.javaidl.JIDLObject.(JIDLObject.java:72) at org.nsidc.idl.nsidc_analyze.(nsidc_analyze.java:17) at org.nsidc.ccaws.model.idl.IDLAnalyze.(IDLAnalyze.java:71) at org.nsidc.ccaws.model.PlotPackageImpl.doPlot(PlotPackageImpl.java:389) at org.nsidc.ccaws.model.PlotPackageImpl.run(PlotPackageImpl.java:164) 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy187.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) |#] After some poking around, we realized that the issue may be that we had our library pointing at the .../bin/bin.linux.x86 folder, but since we are running it on a 64-bit machine, it should probably point at .../bin/bin.linux.x86_64. However, now when we try to make the IDL call, this error is shown: [#|2010-09-16T13:14:55.929-0600|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=30;_ThreadName=Thread-1;|16 Sep 2010 13:14:55,909 [Thread-42] TRACE org.nsidc.ccaws.model.idl.IDLAnalyze - IDL Subsystem: idl_opserver: error while loading shared libraries: libidl_ops.so.7.0: wrong ELF class: ELFCLASS64 |#] [#|2010-09-16T13:14:55.937-0600|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;|16 Sep 2010 13:14:55,935 [pool-5-thread-2] ERROR org.nsidc.ccaws.model.PlotPackageImpl - Error creating IDLTimeSeries object! com.idl.javaidl.JIDLException[iErr=-999 sMsg=EOF on control pipe] at com.idl.javaidl.JIDLPAL.nativeThrowJIDLException(Native Method) at com.idl.javaidl.JIDLPAL.throwSpecificException(JIDLPAL.java:1069) at com.idl.javaidl.JIDLPAL.throwJIDLException(JIDLPAL.java:1098) at com.idl.javaidl.JIDLPAL.createObject(JIDLPAL.java:378) at com.idl.javaidl.JIDLPAL.createObject(JIDLPAL.java:314) at com.idl.javaidl.JIDLObject.createObject(JIDLObject.java:193) at com.idl.javaidl.JIDLObject.createObject(JIDLObject.java:151) at org.nsidc.ccaws.model.idl.IDLAnalyze.(IDLAnalyze.java:79) at org.nsidc.ccaws.model.PlotPackageImpl.doPlot(PlotPackageImpl.java:389) at org.nsidc.ccaws.model.PlotPackageImpl.run(PlotPackageImpl.java:164) 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.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy188.run(Unknown Source) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) |#] In the JVM settings, we have the following that I've seen referenced in glassfish documentation: -d64 -server And we are using a 64-bit JVM: java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) I'm sure it's something minor we are overlooking, but I can't seem to figure out how to get it to make the calls like it should. Any help would be appreciated.
    You are not authorized to post a reply.