axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: Attachment support.
Date Mon, 05 Nov 2001 08:36:03 GMT

Hi Rick!

A few comments from a brief glance at the code:

* Woo hoo! :)  Thanks for working on this.

* Formatting - please stick with the Axis coding conventions (4 space
indents, no tabs, 80 col lines)

* I'm wondering if there isn't a somewhat nicer way to isolate the stuff
that relies on activation/mail.  The AttachmentsImpl pattern here seems a
little clunky... the MessageWithAttachments subclass idea might actually be
a bit more attractive.... what was the reasoning against that again?

* We won't need to worry about checking for cids vs. URLs in this code -
that'll happen when we resolve HREFs in the
DeserializationContext/Deserializer code - by the time we're calling
getPartByReference(), we already know it's a MIME ref.  (in looking at that
code, I note that the DeserializationContext's mapping of IDs -> IDResolvers
needs some revamping - rather than explicitly registering each ID, we should
be passing the HREF string to a resolver supplier and returning the
LocalResolver if it starts with "#", a MIMEResolver if it starts with
"cid:", etc...)


----- Original Message -----
From: "Rick Rineholt" <>
To: <>
Sent: Sunday, November 04, 2001 2:28 PM
Subject: Attachment support.

> I have been successful in sending a SOAP attachment with the modified
> attached in
> zip file expand in the "current" Axis code base.  If this code can't be
> used out right, I'm hopeful
>  that portions of it might be used in facilitating this functionality.
> WARNING, it was work in progress.
> To build it:
> Unzip in the current Axis code base.
> Add activiation.jar and mailapi.jar to your classpath.
>   (Without these it should still build and functional tests run, but
> attachments won't work).
> It 'should', complete all the functional test.
> If you'd like to test it:
> You need to add the following service to your Axis server deployment.
> --------------------------------------------------
>  <service name="MD5Service">
>   <provider type="java:org.apache.axis.handlers.MD5AttachHandler">
>    <handler:provider type
> ="java:org.apache.axis.handlers.MD5AttachHandler"/>
>   </provider>
>  </service>
> --------------------------------------------------
> Start your HTTPServer  (I only tested with TC 4.0)
> Make sure your server also has activiation.jar and mailapi.jar too
> Then in the  java\test\md5attach directory run the test.cmd
>   - you may need to edit this command to change the url to your http
> server.
> You will have in your temp directory files left over
> that need to be deleted, they are named axis***axis
> (remember work that is in progress)
> What should  happen?  Well, if you just run "test.cmd", it should
>  record the current time, creates a soap envelope that reference the
> attachment which is
> the test.cmd file itself and sends to the server.  The MD5AttachHandler,
> gets the SOAP
> envelope  finds the element that has the reference to the attachment.
> this it gets
> the attachment from the attachments object and then the actual JAF
> datahandler.
> It then records the time and calculates the difference. It then does an
> signature.
> It then sends back the time differences and the MD5 signature in an
> data.
> The MD5AttachTest then displays the time it took to send (assuming sender
> and receiver
> have reasonably synched clocks).  It then does an MD5 signature on the
> local file and
> compares them.  Hopefully they are the same.
> You can use TcpTunnelGui to see it being sent. (Ah, do't try this with a
> 50m file)
> Warning I was really only using this as a workhorse to validate the code.
> Its not pretty for a demo or sample.
> Also I was pointed to by someone to use the as a base and maybe I
> misunderstood, because
> it seem that the Service Client interface there is "deprecated" :-(
>   As an aside,  I ran in to the a dilemma with attachments. I needed a
> Message object to create an
>   attachment in it.  Then I was able to get the SOAP part and from there
> modify the DOM elements
> to reference my attachment.
>  But then I could not find a way to update the envelope in the SOAP part
> since it seems this DOM is only
>  a copy.  I broke what again "I" perceived has the stalemate by adding to
> the SOAPPart a "setSOAPEnvelope".
>  I feel I must have missed something since I would think this would be a
> very common thing to do. Note,
>  I have seen code that after it updates the envelope it creates a new
> message, but then my attachments
>  wouldn't be associated with the new message any more.   Would like to
> how it should be done.
> What it does:
> The sending side is pretty easy it just uses the mailapi.jar to format the
> data.  The difference
>   over SOAP 2x is that it read all data in memory to determine the content
> length.  Won't work for
>   a .5G file.   What I did was two things: first I fixed it so that the
> only encoding type I send
> is 8bit for the SOAP part.  Anything else I send with an encoding type as
> "binary".  SOAP 2.x
> use of the mail api reads it in memory which the mail api then determined
> if it was safe to
> be sent as "mail"  for most binary data this meant encoding it to Base64
> encoded printable.
> Another over head SOAP 2.x had..  Anything other than mail is 8 bit safe
> and this is not necessary.  By not using
> these encodings I can directly calculate the content length. So nothing is
> ever read in to
> memory.
> For SOAP 2.x on the receiving side, all the attachments were read in
> memory.  What this code
> does is manages the stream itself.  If and only if the stream is
> multipart-related it creates a filtered
> stream for the rest of the SOAP engine (i.e. it only perceives to "see"
> SOAP data stream). Note
> that if this is not a multi-part stream the SOAP engine gets the actual
> stream.  It then filters out all attachments.
> For small attachments the data is kept in memory.  Once a limit is hit all
> the data of the attachment is sent
> to disk.  What is the limit?  It gets sets for each attachments and
> be made in some way to differentiate
> by mime type or if possible the actual service or parameter.
> The good news:
> -------------------
> Is that "I" (and if you try it, hopefully you) been able to send BIG
> I have tested
> routinely with zip files that are 60M and only take a minute or two to
> send.  I have tested once with
> a .5 G and that completed too in the proportional time.  Remember, for big
> files, if your sending and receiving
> on the same machine you won't get as good of a performance since your
> reading and writing (caching)
> at the same time (i.e. competing for disk space).
> While there is some buffer to make it efficient for finding mime
> boundaries,  the SOAP content,
> is not read entirely in memory.  Potentially attachments that are received
> before the SOAP content
> are cached.  Attachments, following the SOAP content are read in when they
> are referenced.
> The bad news:
> ---------------------
> "This was work under progress"
> Admitting, it is still rough with tons of to-dos.
> It's only there for handlers and not filtered to the higher level RPC
> level.
> File caching needs to clean up after itself.
> On the received side there needs to be support for receiving encoding
>  "Base64" and "quoted printable" for a future mail transport and for
> servers that
>  insist on sending these encodings on 8bit safe protocols.
> I only enabled it for the HTTP server and not any of the other servers in
> Axis.
> Code to make  the attachments available  to the Java RPC layer
> Handling refernces to Content-Location as well.
> Code to remove attachments from the message.
> There are many more....
> Again, I hope this can  help in getting attachment  support in
> Axis.  If this, or something comparable gets into Axis
> soon, I'd be willing to lend a hand in tackling  issues that will help
> complete this feature in Axis.
> (See attached file: attached file: activation.jar)(See
> attached file: mailapi.jar)
> Rick Rineholt

View raw message