axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <>
Subject Re: Attachment support.
Date Mon, 05 Nov 2001 13:57:18 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 can see were I've easily transgressed the 80 col. rule.
  I was not aware of that.  Does this include comments?  I think
  comments in line with code are helpful and 80 cols are really putting a
  squeeze on getting code content on a line and a really meaningful
  comment.  If comments are included has anyone considered to making
  them exempt?
 Did you detect tabs?  I couldn't.  Can you please point out the file so I
   could investigate it some more.
 I also believe the code was indented by 4 spaces.

>* I'm wondering if there isn't a somewhat nicer way to isolate the stuff
>that relies on activation/mail.
What there is now does isolate.  Infact all this work was just checked
friday; I only assumed that given its recent check in that this is the
that the Axis community has settled on.
>The AttachmentsImpl pattern here seems a
>little clunky... the MessageWithAttachments subclass idea might actually
>a bit more attractive.... what was the reasoning against that again?
I really don't know.  I remember seeing a lot of discussion  around it
on the topic but I decided not to follow it  too closely and concentrate on
getting real
bits to fly between a SOAP client and Server in a scaleable way.  Since,
this was the most recent
check in I "assumed" it was what the Axis community as a whole decided
on.  I just spent a whole beautiful Sat. and half a Sun. refactoring
something I had
to fit to this model to hopefully get a little real progress done rather
than incite another
couple of weeks of debate.  "Make peace ... and prosper".

>* 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
>code, I note that the DeserializationContext's mapping of IDs ->
>needs some revamping - rather than explicitly registering each ID, we
>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...)
Hmm.  Little confused about this   Take the scenario where there is a
a global handler that needs to do signature checking on ALL content
attachments.  My "understanding" is that Deserializers come in to play for
Java RPC API and that handlers should be able to get at and examine and
modify "raw" message content.  I shouldn't think that at this stage either
or deserializer should come into play.  I can envision that the serializers
and deserialzers
at the Java RPC API service level resolves all attachment refernce and
applies  serializers
or deserialzers to attachments maybe converting attachment content by
parameter or mime type
to a String DOM, JAF Datahandler or for example a text/xml content to an
encapsulated SAXSDeserialser that when
the user registers events for and starts seeing SAX events for the
presumbable XML content in
the attachment.  All of this should be configurable the service via
But, handlers shouldn't be at this level right?  They should be able to
call on the message object
and just get the attachment.  If not how do these handlers register their
own TypeMappingRegistry
for attachments?  If they don't  how will global handlers deal with
attachments that are registered to
deserialize differently for different services?

Currently, I don't read the attachment data off the stream until it is
referenced.  Unless, I read
the whole multpart-related  stream in first and hand each parts content-id
and content-location
to the "resolver supplier",
something needs to get back to the stream reading code to and ask it search
for a particular
content-location or content-id to get the data.

I can see when data is coming off the stream that some "resolver supplier"
be informed of
of the parts content-location, or content-id so it may eventually assist in
doing Serialization/Deserializaton.


>----- 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
>> 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
>> Its not pretty for a demo or sample.
>> Also I was pointed to by someone to use the as a base and maybe
>> 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
>> 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
>> data.  The difference
>>   over SOAP 2x is that it read all data in memory to determine the
>> 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
>> "binary".  SOAP 2.x
>> use of the mail api reads it in memory which the mail api then
>> 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
>> 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
>> 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
>> 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
>> before the SOAP content
>> are cached.  Attachments, following the SOAP content are read in when
>> 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
>> 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:
>> attached file: mailapi.jar)
>> Rick Rineholt

Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

View raw message