Frex, I agree with Axton. Despite the fact that Remedy 32Bit apps will run on 64Bit machines, they must use the 32Bit JVM to do so..I don't have any experience in your problem, but if the Java program was written using the 32Bit API's, and needs them, then you must use the 32Bit JVM.
From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Frex Popo Sent: Friday, February 04, 2011 7:28 AM To: arslist@ARSLIST.ORG Subject: JAVA API in a x64 machine using x32 dlls ** Dear listers, I am not a Java person and would need some pointers from those who wrote Java API in the past. The company integrated with some supplier's application using web services. They got into all kind of problems so they decided to go it the Java API route. Someone from the supplier's end wrote some Java program which connects to the remedy server and creates/updates some tickets etc.. He started with a stand alone server which he installed in his machine. He used all the dll. file listed in the API integration manual. He got his program working. He then deployed his program in a WAS61 (websphere web server) in a 32x machine. It worked just fine, or at least what I was told. He then did the same in one of our x64 but machine but it bails during deployment the application gives errors (please see below). They are all pointing to the fact that the dlls are x32 and not 64x. My question is if this is the case, why is it that we got a Mid-Tier which uses x32 libraries working fine in a WAS61 x64 machine? What's different? Where do I look to start with, in order to compare what's on both machines (x32 [where the API works] and x64 [where it does not]), simply because the two machines are different with different software/components/specs etc and not just the Remedy API libraries?? Also, could the Java driver or C driver be used as a test to prove that the API libraries are the culprit? Is there anyway you can emulate a x64 JVM to run the 32x API? Anyway pointers will be very much appreciated as we are quite stuck as to what do next!! Regards frex 3/02/11 9:30:07:663 CET] 0000006e DispatchActio E org.apache.struts.actions.DispatchAction dispatchMethod Dispatch[/editInspeccion] to method 'guardar' returned an exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java: 269) at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:170) at com.eptisa.pavimentos.control.action.GenericAction.execute(GenericAction.jav a:106) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProces sor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at javax.servlet.http.HttpServlet.service(HttpServlet.java:763) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1 096) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper. java:570) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrappe r.java:478) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServl etWrapper.java:90) at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:748) at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1466) at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:119) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(Ht tpInboundLink.java:458) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(Ht tpInboundLink.java:387) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLRea dCallback.java:102) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioRea dCompletionListener.java:165) at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java :217) at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture .java:161) at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136) at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195) at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743 ) at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473) Caused by: java.lang.UnsatisfiedLinkError: com/bmc/arsys/api/Proxy.ARInitialization()J at com.bmc.arsys.api.Proxy.<init>(Unknown Source) at com.bmc.arsys.api.ProxyJRpcBase.<init>(Unknown Source) at com.bmc.arsys.api.ProxyJRpc.<init>(Unknown Source) at com.bmc.arsys.api.ProxyManager.createProxy(Unknown Source) at com.bmc.arsys.api.ProxyPool.get(Unknown Source) at com.bmc.arsys.api.PoolingProxyManager.getProxy(Unknown Source) at com.bmc.arsys.api.ARServerUser.logout(Unknown Source) at com.avisa.AvisaServer.logoutServer(AvisaServer.java:93) at com.avisa.AvisaServer.modificarFormulario(AvisaServer.java:120) at com.avisa.Avisa.inspeccionar(Avisa.java:64) at com.eptisa.pavimentos.facade.DFInspeccion.guardar(DFInspeccion.java:273) at com.eptisa.pavimentos.control.action.InspeccionAction.guardar(InspeccionActi on.java:265) _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
