Ticket #400 (closed defect: wontfix)

Opened 16 years ago

Last modified 16 years ago

Remoting broke

Reported by: andrea@… Owned by:
Priority: normal Milestone: 3.1 Maintenance Final
Version: 3.1.261 Severity: blocker
Keywords: Cc:

Description

Switching to the latest maintenance release broke down all my ajax remote calls. The returnValue required is always retuned as an empty field.

The same code works ok on previous version.

Change History

Changed 16 years ago by cfgrok

While we obviously would like to resolve any issues with the RemotingService, this bug report really doesn't give us very much information in order to ascertain what the problem may be.

Although this FAQ was written to address asking questions on the Model-Glue mailing list, the same general principles apply when submitting a bug report -- the more information you provide, the more likely we will be able to identify the issue at hand:

What Information Should I Provide for the Mailing List

That said, there were some significant changes to the RemotingService, most notably the fact that remote requests for an event will now run the full Model-Glue event lifecycle. See this post on the mailing list for the details:

http://groups.google.com/group/model-glue/browse_thread/thread/449e5362a1f5b37a

Given that, I would suspect that the most likely cause for the issue you have encountered would be something that is executing via one of the built-in events/message-listeners, such as onRequestStart.

Changed 16 years ago by andrea@…

I have a maintenance version that brake any MG app using remoting I have on my dev area..... there is no example I can give you. I have tested many service that runs just fine if I call them from browsers and return nothing if called via remoting. Does retrocompatibility is assured ?

Changed 16 years ago by cfgrok

Please review the mailing list post I linked previously, as it describes the details of a significant change to remoting requests, which is the fact that they will now run the full Model-Glue event lifecycle:

http://groups.google.com/group/model-glue/browse_thread/thread/449e5362a1f5b37a

As this is new behavior, it is possible that it may result in issues with remoting requests due to code that is run via the built-in Model-Glue message broadcasts such as onRequestStart. Do you have controller methods fired by any of the built-in message broadcasts that may have an impact on remote requests?

Changed 16 years ago by andrea@…

This call set into event a value called listProvincia ( an array ):

http://va.local/index.cfm/action.doListProvince/regioneId/13/requestFormat/json

If I do the same call with the same parameters via the remote facade ( both in get or post ):

http://va.local/RemotingService.cfc?method=executeEvent&returnformat=json&eventName=action.doListProvince&regioniid=13&returnValues=listProvincia&requestFormat=json

The value listProvincia is an empty string.

While parameters are exactly the same I guess something going on.

While this is a potential traumatic change why do not consider a back compatibility ( also via a config flag ) for the next version so that users have 1 version to update their code ?

Changed 16 years ago by cfgrok

  • status changed from new to closed
  • version changed from 3.1.185 to 3.1.261
  • resolution set to wontfix

In the absence of any evidence to the contrary, we believe that the issue reported here is caused by an interaction with other application code, and is not directly attributable to the changes made to the remoting service.

It is the position of the Model-Glue team that the previous behavior of the remoting service was incorrect, and that in order to fix this issue we have needed to change the implementation in a manner that has the potential to cause such conflicts to arise. While we appreciate that this may require modifications to applications that rely upon the previous, buggy behavior, we nonetheless feel that it is necessary to correct the problem in this manner.

We are more than happy to assist any users that encounter problems in analyzing/debugging their applications to identify and resolve any such conflicts.

Note: See TracTickets for help on using tickets.