<cfset wsURL = "http:// <mywebservicepath>/jira/rpc/soap/jirasoapservice-v2?wsdl"> <cfset CreateObject( "java", "coldfusion.server.ServiceFactory" ).XmlRpcService.RefreshWebService(wsURL) />
Something like this will refresh the webservice if cached dont think this is supported but can be used to help debug. hth Rod. On Fri, Oct 8, 2010 at 2:50 PM, Matthew <matthewbchamb...@gmail.com> wrote: > Hi Gavin > > I've only skim read the thread but you shouldn't need to restart CF. > You just need to refresh the WSDL reference in CFADMIN. CF caches or > reads the WSDL and stores it somehow. I'm sure of it because I've had > similar issues. My code only picks up the modified WSDL once I refresh > it in CFADMIN. It makes sense because request and response definitions > can be complex so if CF had to work this out each time you make a call > it would be a big overhead. Hope that helps. > > Cheers > Matthew > > On Oct 8, 1:21 pm, MrBuzzy <mrbu...@gmail.com> wrote: > > Gav, it depends on your code, but generally the wsdl is not hit on every > request. > > > > Wsdl = web service description language. > > > > When you invoke a method your calling code is passing XML to the web > service endpoint that is described in the wsdl. Look for <soap:address ... > /> in the wsdl that's the actual URL that does all the work. > > > > As discussed earlier there are ways and means or re-reading the wsdl > programmatically and interactively. > > > > But depending on how you write your cf application it may appear that the > calling code is not seeing the new wsdl when it changes (hence your need to > restart) > > > > It's actually possible to publish a web service without wsdl, in other > development environments ie traditional java the wsdl is only useful during > development to generate java objects. The wsdl need not exist at run time. > > > > I hope this helps in some way. I guess you will come back to your > original question - why did you need to restart? > > > > Hard to say but there are a few reasons this can occur. > > > > Sent from my iPhone > > > > On 08/10/2010, at 12:42, Gavin Beau Baumanis <b...@palcare.com.au> > wrote: > > > > > Hi Again everyone, > > > > > I just had a chat with Chris Velevitch and he asked me something that > neither of us knew the answer to - but actually made clear to me what he was > writing in his original reply. > > > > > Lets just assume that the service is on a completely different box / > perhaps even written in some other language. > > > > > I have a CFML application consuming that service. > > > Does my CFML application (or perhaps the underlying CFML engine) cache > the WSDL at all? or is it completely re-read by the consumer every request? > > > > > And neither of us know the answer - but if there is any consumer > caching - could that be the cause of things not behaving? > > > Could the underlying JVM (JRun?) be doing anything - Afterall I > restarted the CF service but not the JRun service during my testing? > > > > > if it mis-behaves again - I'll try restarting the JVM service too - and > see if that makes any differences and write back here with any further > news... > > > But for the time being seems like I have more questions and still no > answers... > > > > > Thanks again to everyone for their help > > > > > Gavin. > > > > > On 08/10/2010, at 11:50 AM, Gavin Beau Baumanis wrote: > > > > >> Hi Chris, > > > > >> I must be wearing my fogged up glasses because I'm not sure I'm > understanding you correctly / or perhaps its the way I have written it? > > > > >> We have multiple clients who currently have their own URL and their > own source code. > > >> They are all physically on the same server using the same instance of > Coldfusion. > > > > >> The staging server and the production server are all set up the same. > > >> Clients log into both - using the staging server for UAT and staff > training. > > > > >> The Login service lives at a URL that resides on the staging server / > staging cf instance. > > >> And basically returns a true / false for a username / password match. > > >> And also returns a struct of relevant user information (username / > surname / fullname / phone / etc. > > > > >> Restarting Apache / CF Service / manually refreshing the WSDL / > clearing the CFC and template caches (via CFAdmin) effects the service and > the calling code. > > >> Thus my confusion with why that process didn't work - but completely > restarting the Staging server did work. > > > > >> So, I suppose my confusion is - how will programatically refreshing > the WSDL be any different to using the CF Admin and furthermore - why would > restarting the box wholly be any different? > > > > >> As always, please contact me if I can be of any futher assistance. > > > > >> Gavin "Beau" Baumanis > > >> Senior Application Developer > > >> PalCare Pty. Ltd. > > > > >> P: +61 -3 9380 3513 > > >> M: +61 -438 545 586 > > >> E: b...@palcare.com.au > > >> W:http://palcare.com.au > > > > >> On 08/10/2010, at 11:15 AM, Chris Velevitch wrote: > > > > >>>> The service is indeed called by CFML code and is also on the same > box as the code that is calling it. > > >>>> It is being used as a webservice, not a CFC call from another > server. > > > > >>> Are the production systems the same as this, i.e. the service server > > >>> is on the same machine as the calling server? > > > > >>> You say the calling server is CFML, are you planning to change the > > >>> cfinvoke on the calling server to include 'refreshWSDL="yes"'? The > > >>> reason I ask this as it sounds like the machine restart caused the > > >>> calling server to clear it's WSDL cache which in effect is the > > >>> equivalent of 'refreshWSDL="yes"'. > > > > >>> Chris > > >>> -- > > >>> Chris Velevitch > > >>> Manager - Adobe Platform Users Group, Sydney > > >>> m: 0415 469 095 > > >>>www.apugs.org.au > > > > >>> Adobe Platform Users Group, Sydney > > >>> October 2010: Flash Builder for SalesForce > > >>> Date: 25th October, 6pm for 6:30 start > > >>> Details and RSVP coming soon > > > > >>> -- > > >>> You received this message because you are subscribed to the Google > Groups "cfaussie" group. > > >>> To post to this group, send email to cfaus...@googlegroups.com. > > >>> To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > > >>> For more options, visit this group athttp:// > groups.google.com/group/cfaussie?hl=en. > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups "cfaussie" group. > > >> To post to this group, send email to cfaus...@googlegroups.com. > > >> To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > > >> For more options, visit this group athttp:// > groups.google.com/group/cfaussie?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "cfaussie" group. > > > To post to this group, send email to cfaus...@googlegroups.com. > > > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > > > For more options, visit this group athttp:// > groups.google.com/group/cfaussie?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
