axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <>
Subject Attachment support.
Date Sun, 04 Nov 2001 19:28:53 GMT
I have been successful in sending a SOAP attachment with the modified files
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
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

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.  With
this it gets
the attachment from the attachments object and then the actual JAF
It then records the time and calculates the difference. It then does an MD5
It then sends back the time differences and the MD5 signature in an element
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 hear
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 or
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
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" the
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 "could"
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 files.
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
File caching needs to clean up after itself.
On the received side there needs to be support for receiving encoding types
 "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
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