You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Rob Jellinghaus <ro...@unrealities.com> on 2001/10/27 00:42:18 UTC
Proposed change to Message API
I'm working on building the infrastructure for streaming sending of Axis attachments. Unfortunately, right now, this is impossible due to the current Message class.
The Message.getAsBytes() and Message.getAsString() methods are heavily used in our send-side code (on client and server side). Of course, these methods kill streaming.
Additionally, currently the Message class only contains the root part (in the SOAP Attachments sense). What happens with attachments? Should getAsBytes() return the entire MIME enclosure, or not?
I propose the following changes to Message:
- Rename getAsBytes(), getAsString() to getRootAsBytes(), getRootAsString()
- Add writeRoot(OutputStream), writeWhole(OutputStream) for streaming
(writeRoot(OutputStream) just writes the root part,
writeWhole(OutputStream) writes the whole MIME enclosure)
- Add getRootContentLength(), getRootContentType(),
getWholeContentLength(), getWholeContentType()
(all of which will be implemented as efficiently as possible)
In Axis installations without mail.jar and activation.jar, and/or without attachment support, the "Root" and "Whole" methods return the same values. i.e. without attachments, the root *is* the whole.
I think it is mildly grotty to introduce these somewhat-duplicated methods. But I also think it clarifies, straightforwardly, each method's job. Basically, attachments break the assumption that the whole message and the root part of the message are the same, and I think that assumption change has to be reflected in Message *somehow*.
(Actual methods to get and set the content of individual attachments is still broken out into a separate interface, and none of these changes to the base Message class would force mail.jar or activation.jar to be available.)
+1's? -1's?
I am underway on this now.
Cheers,
Rob
(p.s. Where's Glen??? Hope he's OK... anyone know?)
Re: Proposed change to Message API
Posted by Glen Daniels <gd...@macromedia.com>.
> Change "SOAP part" to "root part" and I'm sold. (Incidentally, Glen, is
Axis
> SOAP-specific or not, to your mind?)
Here's my take : for v1.0, it is absolutely SOAP specific. I don't know
about the rest of you, but I would really like to get a first complete
version of Axis out the door by the end of the year. Now, this will really
mean a "post-beta-release-candidate" type of thing, since we're using JAX
API's which won't be released yet, but still there's a functionality line in
the sand that I'd like to draw, and revamping to do generic non-SOAP
protocols is something that seems clearly on the other side of that line to
me. Let's do that later if there's a demand for it.
--Glen
Re: Proposed change to Message API
Posted by Rob Jellinghaus <ro...@unrealities.com>.
At 10:46 AM 10/28/2001 -0800, Rob Jellinghaus wrote:
>Change "SOAP part" to "root part" and I'm sold. (Incidentally, Glen, is Axis SOAP-specific or not, to your mind?)
>
>By the way, IDEA indeed rocks :-) using it now. I just wish its syntax checking / correctness checking was
... BETTER. Was BETTER. Specifically, I wish it was as good as CodeGuide. CodeGuide will catch *every* Java compile error, including incorrect exception signatures. IDEA won't catch incorrect exception signatures. :-(
I wish my email correctness checker were better, too.
Cheers!
Rob
Re: Proposed change to Message API
Posted by Rob Jellinghaus <ro...@unrealities.com>.
Change "SOAP part" to "root part" and I'm sold. (Incidentally, Glen, is Axis SOAP-specific or not, to your mind?)
By the way, IDEA indeed rocks :-) using it now. I just wish its syntax checking / correctness checking was
At 11:25 AM 10/28/2001 -0500, Glen Daniels wrote:
>Attachments aren't something that can be "bolted on" to an existing
>mechanism, they have to be designed in at the core, IMHO.
OK, I'm good with that. And I'm good with having an explicit Part API, which will *not* be javax.mail.BodyPart since we don't want to mandate having mail.jar around if you don't want attachment support.
>Take a look at the JAXM SOAPMessage class and its associates:
>
>http://java.sun.com/xml/jaxm/jaxm-0_94-pfd1-spec.pdf
OK!
Cheers!
Rob
Re: Proposed change to Message API
Posted by Glen Daniels <gd...@macromedia.com>.
Hi, Rob!
Attachments aren't something that can be "bolted on" to an existing
mechanism, they have to be designed in at the core, IMHO.
Take a look at the JAXM SOAPMessage class and its associates:
http://java.sun.com/xml/jaxm/jaxm-0_94-pfd1-spec.pdf
I think that a similar pattern makes a lot of sense. Messages contain
parts, and there's a distinguished SOAP part. In the case of a non-MIME
message, there is ONLY the SOAP part. When you say Message.getAsBytes(),
you get the whole message incl MIME wrapper. You could also do
SOAPPart.getAsBytes() if you want... make sense?
--Glen
P.S. I'm here :) I'm back from a conference earlier this week, and still
catching up. Will be replying to a bunch of the recent threads today.
----- Original Message -----
From: "Rob Jellinghaus" <ro...@unrealities.com>
To: <ax...@xml.apache.org>
Sent: Friday, October 26, 2001 5:42 PM
Subject: Proposed change to Message API
> I'm working on building the infrastructure for streaming sending of Axis
attachments. Unfortunately, right now, this is impossible due to the
current Message class.
>
> The Message.getAsBytes() and Message.getAsString() methods are heavily
used in our send-side code (on client and server side). Of course, these
methods kill streaming.
>
> Additionally, currently the Message class only contains the root part (in
the SOAP Attachments sense). What happens with attachments? Should
getAsBytes() return the entire MIME enclosure, or not?
>
> I propose the following changes to Message:
>
> - Rename getAsBytes(), getAsString() to getRootAsBytes(),
getRootAsString()
> - Add writeRoot(OutputStream), writeWhole(OutputStream) for streaming
> (writeRoot(OutputStream) just writes the root part,
> writeWhole(OutputStream) writes the whole MIME enclosure)
> - Add getRootContentLength(), getRootContentType(),
> getWholeContentLength(), getWholeContentType()
> (all of which will be implemented as efficiently as possible)
>
> In Axis installations without mail.jar and activation.jar, and/or without
attachment support, the "Root" and "Whole" methods return the same values.
i.e. without attachments, the root *is* the whole.
>
> I think it is mildly grotty to introduce these somewhat-duplicated
methods. But I also think it clarifies, straightforwardly, each method's
job. Basically, attachments break the assumption that the whole message and
the root part of the message are the same, and I think that assumption
change has to be reflected in Message *somehow*.
>
> (Actual methods to get and set the content of individual attachments is
still broken out into a separate interface, and none of these changes to the
base Message class would force mail.jar or activation.jar to be available.)
>
> +1's? -1's?
> I am underway on this now.
> Cheers,
> Rob
>
> (p.s. Where's Glen??? Hope he's OK... anyone know?)
>
>
>
>