[flexcoders] Re: Problem calling a web service - error 2032
Yep, this error doesn't give any info... I took a look at the server side, apparently the server (Java xFire) was throwing an error "There must be a method name element.". I'm stopping the digging here since I have a work around - adding a dummy parameter to the method and avoiding a web service method with no parameters works around this annoying bug. I must say that this together with other bugs I encountered with Flex webservices makes me wonder if this is a mature technology... G --- In flexcoders@yahoogroups.com, "Adrian Resa Jones" wrote: > > This is a very annoying error that appears to have a zillion different > causes - all it means is that something went wrong when flex tried to > execute your code - it could mean that the file was not found or it > could mean that it bombed for some reason. > > After hunting around on the web for endless hours, I figured out that > the only way to resolve this error is to debug the webservice or > function call by typing in the url directly. > > In my case, It turned out to be the simple fact that I copied over the > wrong (buggy) file to my server thanks to the way that flexbuilder > caches source code to my local host. > > --- In flexcoders@yahoogroups.com, "guy.tomer" wrote: > > > > Hello, > > > > I've been struggling half a day with this Error 2032 returning from > > one of the APIs in my webservice. This API already worked and somehow > > after regenerating the proxies it stopped! Finally I figured out the > > only difference between this API and the others that work is that this > > one gets no parameters... crazy as it sounds when I added a parameter > > to the API and regenerated the classes everything began to work... > > > > Does anyone have an explanation? or do I have to leave this ugly dummy > > and mark it as another bug in the generated classes implementation... > > > > Anyway - at least maybe this will save others the fight. > > > > Guy > > >
[flexcoders] Re: Problem calling a web service - error 2032
This is a very annoying error that appears to have a zillion different causes - all it means is that something went wrong when flex tried to execute your code - it could mean that the file was not found or it could mean that it bombed for some reason. After hunting around on the web for endless hours, I figured out that the only way to resolve this error is to debug the webservice or function call by typing in the url directly. In my case, It turned out to be the simple fact that I copied over the wrong (buggy) file to my server thanks to the way that flexbuilder caches source code to my local host. --- In flexcoders@yahoogroups.com, "guy.tomer" wrote: > > Hello, > > I've been struggling half a day with this Error 2032 returning from > one of the APIs in my webservice. This API already worked and somehow > after regenerating the proxies it stopped! Finally I figured out the > only difference between this API and the others that work is that this > one gets no parameters... crazy as it sounds when I added a parameter > to the API and regenerated the classes everything began to work... > > Does anyone have an explanation? or do I have to leave this ugly dummy > and mark it as another bug in the generated classes implementation... > > Anyway - at least maybe this will save others the fight. > > Guy >
[flexcoders] Re: Problem calling a web service - error 2032
Check out this blog on the error; tons of good info to help you: http://www.judahfrangipane.com/blog/?p=87 - Alex --- In flexcoders@yahoogroups.com, "guy.tomer" wrote: > > Hello, > > I've been struggling half a day with this Error 2032 returning from > one of the APIs in my webservice. This API already worked and somehow > after regenerating the proxies it stopped! Finally I figured out the > only difference between this API and the others that work is that this > one gets no parameters... crazy as it sounds when I added a parameter > to the API and regenerated the classes everything began to work... > > Does anyone have an explanation? or do I have to leave this ugly dummy > and mark it as another bug in the generated classes implementation... > > Anyway - at least maybe this will save others the fight. > > Guy >
