Flex : LCDS Service returning null Asynctoken when executed 2nd time

Question

I'm developing a Flex application using RobotLegs, LiveCycle DS & Java. I'm trying to implement an update function, using LCDS, but I'm running into some strange behaviour:

This is the ActionScript code within a RobotLegs' execute command, used to perform the update:

 var token:AsyncToken = services.requestService.commit(new Array(model.currentRequestDetail));
 responder = new AsyncResponder(resultHandler, faultHandler, token);
 if ( token ) token.addResponder(responder);

The model.currentRequestDetail I'm trying to update is a RequestDetail Object:

[Managed]
[RemoteClass(alias="be.fgov.mobilit.td.lcds.vo.RequestDetail")]
public class RequestDetail {

    public var id:Number;
    public var request:Request;
    public var task:Task;

    /**
     * Constructor
     */
    public function RequestDetail() {
    }
}

The first time the Actionscript code is executed, everything works fine. The AsyncToken is nicely returned by the services.requestService.commit() function, the resultHandler is executed as expected, and my object is updated in the GUI.
However, the second time this code is executed, my services.requestService.commit() function returns a null value, and my resultHandler is never reached. I suspect we're not even reaching the java assembler.

This is how I declared the DataService:

var requestDetailService:DataService = new DataService("requestDetail");
requestDetailService.autoCommit = false;

Both the resultHandler & the faultHandler have the right signature:

resultHandler(result:Object, token:Object = null)
faultHandler(result:Object, token:Object = null)

We're also using a custom java assembler, this is the code:

package be.fgov.mobilit.td.lcds.assemblers;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import be.fgov.mobilit.td.lcds.vo.RequestDetail;
import flex.data.ChangeObject;
import flex.data.assemblers.AbstractAssembler;

public class RequestAssembler extends AbstractAssembler {

public RequestAssembler() {
    // TODO Auto-generated constructor stub
}

public RequestDetail getRequest(Map<String, Object> identity) {
    return ServiceUtility.getLcdsService().getRequestDetail(identity);
}

public List<ChangeObject> syncRequest(List<ChangeObject> changes) {
    Iterator<ChangeObject> iterator = changes.iterator();
    ChangeObject co;
    while (iterator.hasNext()) {
        co = (ChangeObject) iterator.next();
        if (co.isUpdate()) {
            co = doUpdate(co);
        }
    }
    return changes;
}

private ChangeObject doUpdate(ChangeObject co) {
    RequestDetail requestDetail = (RequestDetail) co.getNewVersion();
       co.setNewVersion(ServiceUtility.getLcdsService().updateRequestDetail(requestDetail));
    return co;
}
}

This is the assembler's configuration:

<destination id="request">
    <properties>
<source>be.fgov.mobilit.td.lcds.assemblers.RequestAssembler</source>

        <scope>application</scope>

        <metadata>
            <identity property="id" />
            <identity property="task" />
        </metadata>

        <server>
            <get-method>
                <name>getRequest</name>
            </get-method>
            <sync-method>
                <name>syncRequest</name>
            </sync-method>
        </server>
    </properties>
</destination>

Long story short:
Does anyone have a clue/experience, why the 2nd time I execute the services.requestService.commit(); function it returns a null Asynctoken?

Thx in advance!

As requested, I added the (stripped) code from my services class. As you can see, nothing really special going on:

package be.fgov.mobilit.services {
import mx.data.DataService;
import mx.messaging.Consumer;
import mx.messaging.events.MessageEvent;
import mx.rpc.http.HTTPService;

public class LiveCycleServices {

    public var requestService:DataService;

    public function LiveCycleServices() {           

        requestService  = new DataService("request");
        requestService.autoCommit = false;
    }


    /**
     * @param   MessageEvent    The event object that is dispatched by the Flex framework
     * @return  void
     * 
     * This message captures the server push messages that need to trigger an update
     * of the task list, since this is specific for every client and cannot be 
     * determined on the server side, coming from LiveCycle.
     */
    private function messageHandler(event:MessageEvent):void {
        taskListService.refresh();          
    }
}
}

This is the chode where my result- & faulthandlers are added:

var token:AsyncToken = services.requestService.commit(new   Array(model.currentRequestDetail));
var responder:AsyncResponder = new AsyncResponder(resultHandler, faultHandler, token);
if ( token ) token.addResponder(responder);

Answer 1

The aysnctoken returns null when you have no changes to commit. Hope this helps.

Answer 2

WWW, This isn't really an answer as such, but I need more space than a comment will give me. However, I'm not seeing how all your code is connected well enough to give you a good answer.

In general, the result and fault signatures should not look like what you describe as the "right" signature. The AsyncToken is expecting an IResponder, which whose fault and result mentods have a single parameter that is an Object. In general, this will be called with the fault or result event (as appropriate).

Now I am going into territory that is, for me, purely theoretical. It looks like to me that the DataService Class might possibly create just a single AsyncToken, since the connection is kept open. If that is the case, it is possible that the erroneous method signature damages the AsyncToken to the extent that it can't be returned for use by the method. I didn't see anything in the code that you pasted that looks like it calls your result and fault methods in a custom way.

I strongly doubt that the problem is in the Java code. AFAIK, the AsyncToken is created and set up to call the functions in the responder before the call is even made (at least that is how it seems to work with HTTPService or amf). I would expect that there's some error that is being "helpfully" suppressed, so you might benefit from stepping through the code.

I would suggest that you step back a bit and look a bit harder at the "S" part of the MVCS architecture implied by Robotlegs, and create a separate service Class that manages the whole thing, and merely kick off the process from a Command, rather than trying to pass control back and forth between your commands and services. As a side benefit, you can then swap out instances of the real service for test services when you don't need to be connected to the actual data (such as for doing design work).