You could do it another way. If you don't trust the client to return an ack, then the last piece of code on the serverside that can get called is a response handler. In the response handler, you get access to the entire soap message. The response handler will not get the response soap message until the implementation has completed its processing (hence the streaming of the output file must have completed too). Therefore, you could do the file deletion, or the triggering at least, in the response handler. (Response handlers are meant for post-processing work, such as cleanup). -jeff
-----Original Message----- From: Andrew Martin [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 10:05 AM To: [email protected] Subject: Re: Axis2 events handling How are you passing the file to Axis2? If you're just passing an InputStream, you could write your own wrapper FilterInputStream that erases the file in its close method or in its read methods whenever -1 is returned. Andrew Elmouj wrote: > Hello Upul, > > Thanks for your reply. Actually this will work and I have already > thought about it; the problem I found with this solution is that the > deletion of the file (in the server side) is after an acknowledgment FROM > the client. this ACK could be easily bypassed: I mean, no one is obliging > people using my service to develop a client that acknowledges receipt of the > file !!! hence making it possible for the file to reside on the server. For > your concern about if the file is lost, this is not a problem because the > file the server sends to a client is an encryption of a file sent from > Client to Server, hence if there is any problem (which is very very very > rare since Axis2 over TCP is almost error free I guess), the client will > just re-request the encryption of his file. So, I am really looking for a > thing that tells me that the last byte has been sent to the client. > > Thanks again, > > Elmouj, > > > Upul Godage wrote: >> Hi, >> >> If you mean you are having a web service which provides files on request, >> let's say, requested by reference number, best thing to do is to have >> another operation in the web service. So that after client gets the >> payload >> and, let's say client has processed or saved it successfully, it will call >> that operation, saying 'got the payload okay for this reference number.' >> Otherwise even though the file is transferred successfully, there could be >> an exception on the client side and the file is lost from both sides. >> >> Upul >> >> >> On 9/5/07, Elmouj <[EMAIL PROTECTED]> wrote: >>> >>> >>> Hello, >>> >>> I have been using Axis2 for a month now and it's really powerful and easy >>> to >>> use. However, the last two days I got stuck looking for a way to access >>> an >>> event triggered when the last byte of the server response is sent to the >>> client; so I decided to post on this forum hoping to get a clue to this >>> issue :( . In other words, I want a way by which I could be informed when >>> the last byte of the server's response is sent because I need to execute >>> some tasks after this event has been triggered (I need to delete a file >>> after the client downloads it). >>> >>> Thanks in advance, >>> >>> Elmouj >>> -- >>> View this message in context: >>> http://www.nabble.com/Axis2-events-handling-tf4383721.html#a12496874 >>> Sent from the Axis - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > -- Andrew Martin Computer Programmer Regenstrief Institute, Inc. 410 West 10th Street, Suite 2000 Indianapolis, IN 46202-3012 Phone: (317) 423-5542 Fax: (317) 423-5695 [EMAIL PROTECTED] Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose. If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
