I have an AIR app with the following EXIT handler defined:
NativeApplication.nativeApplication.addEventListener(Event.EXITING, applicationExitHandler);
applicationExitHandler makes an asynchronous logout request via an HttpService. Since this is asynchronous, it looks like the Application's exit() method returns before the logout request is actually made.
How can I make sure the request completes before exit() returns?
Override the default behavior. Cancel this event. Call the service then.Add a request handler/ fault handler to your service. On completion either the result or the fault handler is called. This is when you can safely exit the app (of course if signout fails, you may need extra processing). From the docs:
exiting
Dispatched when the application exit sequence is started.
The exiting event is dispatched when application exit is initiated by the operating system; for example, when a user issues the Cmd-Q key sequence on Mac OS X, or when the autoExit property of the NativeApplication object is true and the last application window is closed. Canceling this event prevents the application from exiting.
Note: Calling the NativeApplication exit() method does not cause an exiting event to be dispatched. To warn components of an impending exit, dispatch the exiting event before calling exit()
The Event.EXITING constant defines the value of the type property of an exiting event object.
Related
I am trying to identify when a servlet is initilazed (not the init() method called), when container try to load an individual servlet ? Or, any mechanism which keeps track of servlet initialized / destroyed / pending to load.
I am aware of the ServletContextListner, which invoked on application start & shutdown. But, I am looking for kind of listener, which probably trigger on individual servlet load / destroy event.
So, scenario would be like :
/Servlet1
/Servlet2
An listener which trigger on servlet1 load and then for Servlet2.
I guess this is the listener you are looking for .You want to know each time a request comes in, so that you can log it.
javax.servlet.ServletRequestListener . Following are the methods requestInitialized requestDestroyed
Sometimes main BPEL process doesn't receive a callback message from asyncronous process.
Asyncronous process invokes the callback and completes successfully, but the main process stays in active status waiting for receive incoming activity.
Main process continues to execute after manual request to callback endpoint (request contains same content as in asynchronous process's output variable).
Usually same callback work successfully.
Can any one explain what the difference is between the following methods of WorkflowApplication:
Abort
Cancel
Terminate
After further investigating this issue, I want to summarize the differences:
Terminate :
the Completed event of the workflow application will be triggered
the CompletionState (WorkflowApplicationCompletedEventArgs) is Faulted
the Unloaded event of the workflow application will be triggered
the workflow completes
OnBodyCompleted on the activity will be called
Cancel:
the Completed event of the workflow application will be triggered
the CompletionState (WorkflowApplicationCompletedEventArgs) is Cancelled
the Unloaded event of the workflow application will be triggered
the workflow completes
OnBodyCompleted on the activity will be called
Abort:
the Aborted event of the workflow application will be triggered
the workflow does not complete
An unhandled exception
triggers OnUnhandledException
in this eventhandler the return value (of type UnhandledExceptionAction) determines what will happen next:
UnhandledExceptionAction.Terminate will terminate the workflow instance
UnhandledExceptionAction.Cancel will cancel the workflow instance
UnhandledExceptionAction.Abort will abort the workflow instance
Each will trigger the corresponding events explained above
Update: Abort does not seem to trigger unloading of the instance in the SQL persistence store. So it seems to me, you better use Cancel or Terminate and if you have to perform some action based upon the completion status, you can check CompletionState in the Complete event.
First, hats off to Steffen Opel (and his comments below). I failed to catch that my original post linked documentation that was WF 3.5 specific. Did a little more digging around.
For posterity's sake, I have left my previous response below, labelled as WF3.5. Please see WF4.0 for a few notes regarding Canceling, Abort, and Terminate in WF4.0.
WF4.0
Unfortunately, there is little explicit documentation discussing differences in Cancel, Abort, and Terminate in WF4.0. However, from member method documentation,
On Abort, a) activity is immediately halted, b) Aborted handler is invoked, and c) Completed handler is not invoked.
On Cancel, a) activity is given a grace period to stop gracefully after which a TimeoutException is thrown, b) Completed handler is invoked.
On Terminate, a) activity is given a grace period to stop gracefully after which a TimeoutException is thrown, b) Completed handler is invoked.
The differences between Abort and Cancel/Terminate is quite striking. Simply call Abort to kill a Workflow outright. The difference between Cancel and Terminate is more nuanced. Cancel does not require any sort of reason (it is a void parameterless method), whereas Terminate requires a reason (in either string or Exception format).
In all cases, Workflow runtime will not perform any implicit action on your behalf (ie Workflows will not auto-self destruct a la WF3.5 Terminate). However, with the highly customizable exception\event handling exposed by the runtime, any such features may be implemented with relative ease.
WF3.5
Canceling
According to Msdn documentation
An activity is put into the Canceling state by a parent activity explicitly, or because an exception was thrown during the execution of that activity.
While Canceling may be used to stop an entire Workflow (ie invoked on root Activity), it is typically used to stop discrete portions of a Workflow (ie either as error-recovery or an explicit action on part of parent). In short, Canceling is a means of Workflow control-flow.
Abort and Terminate
Again, according to Msdn documentation
Abort is different from Terminate in that while Abort simply clears the in-memory workflow instance and can be restarted from the last persistence point, Terminate clears the in-memory workflow instance and informs the persistence service that the instance has been cleared from memory. For the SqlWorkflowPersistenceService, this means that all state information for that workflow instance is deleted from the database upon termination. You will not be able to reload the workflow instance from a previously stored persistence point.
Which is pretty clear in itself. Abort merely stops in-memory execution whereas Terminate stops in-memory execution and destroys any persisted state.
NativeApplication.nativeApplication.exit(); - this method is used for exit the application of flex/air .
application.close(); - this method also used for exit the application of flex/air -
So what is different?
He is referring to NativeApplication.exit() vs WindowedApplication.close().
WindowedApplication.close() Closes the
application's NativeWindow (the
initial native window opened by the
application). This action is
cancelable.
Calling close() on the application window will effectively shut down the application, but using the exit() method on NativeApplication is the proper way to terminate it. See the following link for more info:
http://livedocs.adobe.com/flex/3/html/help.html?content=app_launch_1.html
I am not sure I am understanding your question entirely because I am not finding an application.close() method.
Here is the documentation on NativeApplication, an AIR only class: http://livedocs.adobe.com/flex/3/langref/flash/desktop/NativeApplication.html#exit()
It defines the exit method like this:
Terminates this application.
The call to the exit() method will
return; the shutdown sequence does not
begin until the currently executing
code (such as a current event handler)
has completed. Pending asynchronous
operations are canceled and may or may
not complete.
Note that an exiting event is not
dispatched. If an exiting event is
required by application logic, call
NativeApplication.nativeApplication.dispatchEvent(),
passing in an Event object of type
exiting. Likewise, closing and close
events are not dispatched before
application windows are closed. If
windows should be notified before your
application exits, you can dispatch
closing events for each open window.
If a window close event is required,
call the window's close() method
before exiting.
Here is the documetation on Application, a Flex class: http://livedocs.adobe.com/flex/3/langref/mx/core/Application.html#methodSummary
It does not seem to have a close() method associated with it. Are you possibly confusing the application class with a window class that you need to close before calling the NativeApplication.nativeApplication.exit() ?
I would be happy to help you research this further if you can clarify the question.
One completely exits the application, the other only closes the main window. It's important to understand the difference. On a Mac, for instance, closing all of an application's windows often leaves that application running in the dock. This is rarely the case on Windows, but if you have a dock icon, you should get similar behavior, I think.
We are using objects that at times need to sync up with the server via
the mx.data.DataService, The problem is in case of explicit method
invocation over the dataservice object we are able to trap the fault
events using the fault handlers.
The problem arises when dataservice is sync'ing the object in
background. In case of a fault event (such as session timeout or
server down) the error is not trapped via the fault handler added on
the dataservice using the addEventListener(FaultEvent.FAULT).
Any suggestions on how to trap the fault events generated via
background sync invocations of the DataService?
Try DataServiceFaultEvent.FAULT instead of FaultEvent.FAULT