My 2 cents : (Some of this -may- be close to what you are suggesting; it just IMO over designed... but I know that is the Axis way)
Create a disposal collection that will dispose all attachment resources after the service or call completes. Should be in
a finally, statement.
Provide an interface to handlers and targeted services for both removing and adding attachments to the disposal list.
On the Server side automatically add all received attachments to the disposal list.
Provide mostly for the client the ability on the call/context to turn off the automatic disposal since there may be circumstances
where it may want more control and take charge of the disposal process and iterate over the list it self.
That's it.
On the client side for the most part there is no real need for this since it can receive control after the call and can manage the attachment resources.
On the server side for received attachments, if a fault occurs prior to the desired recipient receiving the attachment it will be deleted.
Once received it can be removed if it's desired to retain it. On sending attachments if the resource is to be deleted after it is sent the
service can add it to the disposal list.
In any case, provide the opportunity to persist attachment resources with out the need to copy them. I know already
several users that envision sending and receiving giga byte sized attachments and prefer there NOT be the REQUIRED need to
always copy them.
Rick Rineholt
"The truth is out there... All you need is a better search engine!"
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: "axis-dev" <[EMAIL PROTECTED]>
cc:
Subject: cleanup of attachment files &c
I want to look at attachement deletion and other cleanup. Here is roughly my
plan
-add package axis.housekeeping for all such stuff
-add interface Disposable { void dispose(); } for all disposable objects
-add class DisposalList that adds, remove and disposes of Disposable
objects. (and demand creates the inner list)
-Add class FileDisposer() that disposes of named files
This much I've just done, but not committed.
So now I need to integrate the attachements with this. How does this sound:-
-add a DisposalList with get accessor to MessageContext
-add MessageContext.dispose() to hand off to DisposalList.dispose()
-When attachments are created from reading a stream, we add them to the
disposal list of the current message context (assuming there is a current
message context).
-modify the transports to
dispose() the message context used in the message
set the current message context to null (encourage GC)
(this could factored into an AxisEngine.disposeCurrentMessageContext()
method)
Now, consequences of this action would be that files wont outlast a message.
So recipients have to save stuff -but they would have to do this for small
messages. The other consequence is that some of the attachmentInputStream
classes have to get the current message context and manipulate it, which
kind of violates my sensibilities; low level classes shouldnt need such
knowledge. But the only other solutions are
(a) static method in class in housekeeping to add disposables to current
context . I'd probably do that anyway for cleanness, but the context is
still there, hidden.
(b) pass a DisposalList down for Attachment classes to add disposables
to. This is cleanest, most fundamental.
Thoughts? Hold off till Axis1.1 ships?
-steve
