Re: Error Messages in 7.6.03/04
Hi, I am almost sure that the flat-files never supported joins, so that may affect "performance" for ITSM and CMDB. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Hi, > > The flat file option was still there in ARS 4.5 by Remedy Corporation. > There were following installation options for: > - Flat File > - IBM DB2 > - Oracle 8 > - MS SQL > and surprise surprise the same DB options were available for 5.0 (by > Remedy Peregrine Inc.). The first ARS server version without flat file > was 5.1 (by Remedy a BMC Software company)! The only DB option for 5.1 > installer were: > - IBM DB2 > - Oracle > - MS SQL > > I wonder how fast flat file would be these days with ITSM Suite ;-) > > -- > Best regards, > > Dariusz Kuzara > > > > > > >> > From my head I remember that flat file was removed in version 5, so >> the latest version should be 4.5 >> >> -- >> H >> >> 2011/2/2 LJ LongWing: >> >>> Well...I know that joins were added in 3.0 or 3.2 and I'm sure flat was >>> still available in 4.x...was great for setting up a standalone dev >>> environment... >>> >>> -Original Message- >>> From: Action Request System discussion list(ARSList) >>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>> Sent: Wednesday, February 02, 2011 8:48 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Error Messages in 7.6.03/04 >>> >>> Hi, >>> >>> I think it was when the Join-forms was introduced, that >>> flat-file-functionality became complicated to maintain... >>> >>> I for one missed it at that time. Why not add support for SQLite and >>> reintroduce the error messages. A simple find/replace from flat-file to >>> SQLite should do it ;-) >>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se >>> >>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): >>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>> logs. >>> Find these products, and many free tools and utilities, at >>> http://rrr.se. >>> >>> Man, I miss thosewhat was the last version that supported that 4.0? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jarl Grøneng Sent: Wednesday, February 02, 2011 8:06 AM To: arslist@ARSLIST.ORG Subject: Re: Error Messages in 7.6.03/04 2011/2/2 Misi Mladoniczky: > Removed messages between 7.6.03 and 7.6.04 > > 500 - Failure while trying to open the flat file database data file > (check > Server-directory setting). > Does this mean that there is no more support for flat file database? :-) > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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"
Are the Archives of the ARSList down?
Dear List, I don't seem to be able to get to the ARSList Archives (http://listserv.rbugs.com/archives/arslist.html). Is the website down, or is something wrong at my end? Dwayne Martin James Madison University ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Are the Archives of the ARSList down?
Yes its indeed giving a problem. Not opening from my side either With Best Regards Rajesh From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org] On Behalf Of Martin, Dwayne - martinrd Sent: Friday, February 04, 2011 6:22 PM To: arslist@arslist.org Subject: Are the Archives of the ARSList down? Dear List, I don't seem to be able to get to the ARSList Archives (http://listserv.rbugs.com/archives/arslist.html). Is the website down, or is something wrong at my end? Dwayne Martin James Madison University _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"
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] 006e 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.java:106) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.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:1096) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:570) at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.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(HttpInboundLink.java:458) at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387) at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102) at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.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.(Unknown Source) at com.bmc.arsys.api.ProxyJRpcBase.(Unknown Source) at com.bmc.a
Re: JAVA API in a x64 machine using x32 dlls
You can not classload a 32-bit native library (JNI) using a 64-bit JVM, and vice versa. You will be constrained to a 32-bit JVM as long as those 32-bit native libraries are required. Axton The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Fri, Feb 4, 2011 at 8:27 AM, Frex Popo wrote: > ** > 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] 006e 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.java:106) > at > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.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:1096) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:570) > at > com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478) > at > com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.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(HttpInboundLink.java:458) > at > com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387) > at > com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:102) > at > com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165) > at > com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217) > at > com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.j
Re: Error Messages in 7.6.03/04
HI'm going to need to differ in opinionI used a system in the 3.2-4.5 range that heavily relied on joins, and I used Flat file for my local machine devI don't see how it couldn't have supported it. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Friday, February 04, 2011 2:54 AM To: arslist@ARSLIST.ORG Subject: Re: Error Messages in 7.6.03/04 Hi, I am almost sure that the flat-files never supported joins, so that may affect "performance" for ITSM and CMDB. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Hi, > > The flat file option was still there in ARS 4.5 by Remedy Corporation. > There were following installation options for: > - Flat File > - IBM DB2 > - Oracle 8 > - MS SQL > and surprise surprise the same DB options were available for 5.0 (by > Remedy Peregrine Inc.). The first ARS server version without flat file > was 5.1 (by Remedy a BMC Software company)! The only DB option for 5.1 > installer were: > - IBM DB2 > - Oracle > - MS SQL > > I wonder how fast flat file would be these days with ITSM Suite ;-) > > -- > Best regards, > > Dariusz Kuzara > > > > > > >> > From my head I remember that flat file was removed in version 5, so >> the latest version should be 4.5 >> >> -- >> H >> >> 2011/2/2 LJ LongWing: >> >>> Well...I know that joins were added in 3.0 or 3.2 and I'm sure flat was >>> still available in 4.x...was great for setting up a standalone dev >>> environment... >>> >>> -Original Message- >>> From: Action Request System discussion list(ARSList) >>> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>> Sent: Wednesday, February 02, 2011 8:48 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Error Messages in 7.6.03/04 >>> >>> Hi, >>> >>> I think it was when the Join-forms was introduced, that >>> flat-file-functionality became complicated to maintain... >>> >>> I for one missed it at that time. Why not add support for SQLite and >>> reintroduce the error messages. A simple find/replace from flat-file to >>> SQLite should do it ;-) >>> >>> Best Regards - Misi, RRR AB, http://www.rrr.se >>> >>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): >>> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy >>> logs. >>> Find these products, and many free tools and utilities, at >>> http://rrr.se. >>> >>> Man, I miss thosewhat was the last version that supported that 4.0? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jarl Grøneng Sent: Wednesday, February 02, 2011 8:06 AM To: arslist@ARSLIST.ORG Subject: Re: Error Messages in 7.6.03/04 2011/2/2 Misi Mladoniczky: > Removed messages between 7.6.03 and 7.6.04 > > 500 - Failure while trying to open the flat file database data file > (check > Server-directory setting). > Does this mean that there is no more support for flat file database? :-) > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
JAVA API in a x64 machine using x32 dlls
Axton is correct, however you almost certainly don't want to really use a 64bit VM, and if this isn't Midtier, you could probably use the native Java API. The Midtier, last time I checked, is 99.9% native library free. Curiously, the only part of the native library it still uses is checking the Midtier configuration password is valid. Perhaps someone at BMC could comment out the one or two lines of code, eject the API, allowing us to deploy much smaller WAR files without Tomcat (and other servlet engines) crashing when the Midtier is restarted (because the JVM can't share the native libraries between classloaders). -- Single Sign On for AR System http://www.javasystemsolutions.com/jss/ssplugin ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: JAVA API in a x64 machine using x32 dlls
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] 006e 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)
Re: JAVA API in a x64 machine using x32 dlls
Hot deployments would sure make development and deployments a lot easier (and more productive - less development time and less downtime). Getting rid of the native library dependencies would make that possible. Axton Grams The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Fri, Feb 4, 2011 at 9:24 AM, John Baker wrote: > Axton is correct, however you almost certainly don't want to really use > a 64bit VM, and if this isn't Midtier, you could probably use the native > Java API. > > The Midtier, last time I checked, is 99.9% native library free. > Curiously, the only part of the native library it still uses is checking > the Midtier configuration password is valid. > > Perhaps someone at BMC could comment out the one or two lines of code, > eject the API, allowing us to deploy much smaller WAR files without > Tomcat (and other servlet engines) crashing when the Midtier is > restarted (because the JVM can't share the native libraries between > classloaders). > > > -- > Single Sign On for AR System > http://www.javasystemsolutions.com/jss/ssplugin > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > 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"
Re: Are the Archives of the ARSList down?
It was having a mid-winter tantrum after the snowfall yesterday. It is feeling better now. However as it is a 6 year old server it is going to have to be put to sleep permanently soon :-) For some reason on Friday mornings the web service is often not responding and so far I seem to have to reboot, recycling the listserv and all the web services doesn't wake it up, if anyone has a suggestion please email me directly. thanks Dan _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Martin, Dwayne - martinrd Sent: February 4, 2011 7:52 AM To: arslist@ARSLIST.ORG Subject: Are the Archives of the ARSList down? ** Dear List, I don't seem to be able to get to the ARSList Archives (http://listserv.rbugs.com/archives/arslist.html). Is the website down, or is something wrong at my end? Dwayne Martin James Madison University _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"
Logging a consume web service with filter
In the 7.1 (and prior) system I could see the XML being sent out from the ARS server in the arplugin.log. Now with 7.6.03 (and probably 7.5 did this also) I cannot log the XML payload. Does anyone know what parameters I might need to set (either in the pluginsvr_config.xml or the log4j_pluginsvr.xml file)? Fred ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Logging a consume web service with filter
Fred, Update your log4j_plgunsvr.xml to log debug instead of 'warn'. That gives you the detail you are looking for. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Friday, February 04, 2011 1:55 PM To: arslist@ARSLIST.ORG Subject: Logging a consume web service with filter In the 7.1 (and prior) system I could see the XML being sent out from the ARS server in the arplugin.log. Now with 7.6.03 (and probably 7.5 did this also) I cannot log the XML payload. Does anyone know what parameters I might need to set (either in the pluginsvr_config.xml or the log4j_pluginsvr.xml file)? Fred ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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"
Re: Logging a consume web service with filter
Thanks ... That worked -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, February 04, 2011 3:09 PM To: arslist@ARSLIST.ORG Subject: Re: Logging a consume web service with filter Fred, Update your log4j_plgunsvr.xml to log debug instead of 'warn'. That gives you the detail you are looking for. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Friday, February 04, 2011 1:55 PM To: arslist@ARSLIST.ORG Subject: Logging a consume web service with filter In the 7.1 (and prior) system I could see the XML being sent out from the ARS server in the arplugin.log. Now with 7.6.03 (and probably 7.5 did this also) I cannot log the XML payload. Does anyone know what parameters I might need to set (either in the pluginsvr_config.xml or the log4j_pluginsvr.xml file)? Fred ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Midtier & SRM Application Settings
We have users that are getting email notifications concerning tickets that contain a bad url. Example: http:///arsys//servlet/ViewFormServlet?form=NTE%3aNotifie r&server=.thecreek.com&eid=NTS03629234 I'm trying to understand what builds this url and have run out of ideas. I've looked at the SRM Application Settings form and I'm seeing possible conflicts between the AR Server Value for MidTier Configuration & URL To Request Entry console fields. In the Mid Tier Path field I have the correct name for the Web Server Name. 1. In the AR Server Value for MidTier Configuration it shows: AppServerName.thecreek.com 2. In the URL To Request Entry console field it shows: http://AliasAppServerName.thecreek.com/arsys/forms/AppServerName.thecree k.com/SRS:ServiceRequestConsole/ I can't modify these two fields in this form so I'm asking where this information is pulled from so I can make the necessary changes to get the email notification url's to work. I hope I'm making sense ? Thanks for your time and help. Larry B. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
