Hi Dennis, Following is what I understood about your proposal for MTOM after reading the chat log...Please correct me if I'm wrong.. JIBX expects a raw input stream of the SOAP envelope with xop:include's.JIBX handles the XOP:Include internally, but it needs Axis2 to do the mime parsing.. The interface you expects Axis2 to provide an interface with a method to access the InputStream of the SOAP envelope together with the methods to access DataHandlers/inputStreams of subsequent mime parts given the content-id.
Also it seems that you have the misunderstanding that Axis2 will build the whole OM if somebody needs to access the data referred in a XOP:Include.. Let's consider a use case of Axis2 receiving a message which refers to an MTOM attachment from a header.. 1. Axis2 receives the message and looking at the content-type of the message Axis2 decides whether it's a MTOM/SWA/pure XML. 2. In the case of a MIME message (MTOM or SWA) Axis2 reads in the root mime part containing the envelope and stores it in a DataHandler..Then takes and InputStream from the DataHandler and gives it to the StaxReader for the normal XML processing to be done..The data in this mime part will be directly streamed to a file, If the the file caching is switched on and the size of the part is bigger than the threshold value.. Direct streaming of the contents of the Root part to the StaXReader till the user requests the subsequent mime parts would have been the ideal scenario. But we decided it to be a post 1.0 goal at that time.. 4.References to the MIMEParser and the attachments are stored in the MIMEHelper class and the user can access it directly if needed.. This takes care of deferred parsing of Mime parts and storing the unused parts in Memory or temp files for future use.. Deferred parsing of MIME parts means that we will parse the stream only till we get the required mime parts.. 5. Axis2 starts processing of the headers and reads in the XOP:Include, which in turn would create an OMText instance with just a pointer to the relevant MIME part. Axis2 is not doing any actual readings of the relevant MIME part even at this point.. 6. Somebody needs to access the data in the above created OMText and calls it's getDataHandler method. At this point Axis2 MIME parser goes ahead and read the relevant MIME part. But the OM will **not** get created irrespective of whether the Caching is ON or OFF.. Remaining InputStream for the Envelope is buffered in a File or in memory as a FileDataSource of MemoryDataSource depending on the size.. My suggestion to your proposal is to use the MIMEHelper to access the attachments. We can also add a method to access the inputStream of the root part without much trouble.. We are also in the process of adding attachment streaming capability to the MIMEHelper, which is a blocker for 1.0.. Functionality of the MIMEHelper might get delegated to SOAPMessage and it's currently under discussion. Personally i prefer to have SOAPMessage with well defined consistent API's for attachment handling... <Quote Dennis> The second part of this interface deals with attachments. It gives the SerializationTarget (which would be transport-dependent, of course) the control over what actually gets sent as an attachment, and provides the data to be output as an attachment in the form of either a stream or an array of bytes. This would allow us to fix the current broken output behavior which forces generation of a fully-expanded OM tree for every message being sent, just so the transport code can check for anything it wants to send as an attachment. </quote> Current behaviour of traversing the tree to find whether there are any optimised parts is a hack till the MTOM policy comes in to play.. When MTOM policy is there it'll define whether to send the message inside a MIME envelope or not.. Till that we can use a message level flag like Glen suggested in the chat to avoid traversing the tree.. Also with with the ongoing improvements like attachments streaming ability and Attachment API we can avoid the above behavior even in a SOAP intermediary.. IMO the ability to decide what data to be optimised should remained on the hands of the user.. Even in the current impl data to be output as attachment is given as streams or array of bytes using DataHandlers.. Please provide a more detailed explanation of the inner workings of the above proposed way of handling attachments.. <quote Glen> I'm saying that I don't know the DH API well enough to know if we can subclass it or whatever in order to get a "future-looking" DH. If we can't, we'll need a wrapper class. </quote> What we can do is to sub class the Data Sources.. Data Sources are the actual data containers inside the Data Handlers.. We are already doing this in the case of FileDataSource, which actually contains a just a file pointer inside... <quote Glen> What we want is a "thingy" which can be stored away and LATER used to get the real attachment data after all XML pulling is done </quote> IMHO we are doing the exactly the same thing using OMTexts.. Currently we are doing this with more flexibility and of course with a catch.. Flexibility is given by allowing the users to get the real attachment data if they wish while pulling the XML.. Catch is that we are buffering the SOAP Envelope in the MIME Parser which is underneath the StaxReader... Unfortunately these days I'm busy with my final year project which is due in another months time and hardly find any time to work on Axis2. It is the cause to the suggested improvements to Attachment codes like streaming and defined API's getting delayed so much... ~Thilina On 3/30/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote: > For the JAXB 2.0 handling of attachments see > http://java.sun.com/javase/6/docs/api/javax/xml/bind/attachment/AttachmentMarshaller.html > and > http://java.sun.com/javase/6/docs/api/javax/xml/bind/attachment/AttachmentUnmarshaller.html > These are set on the marshaller and unmarshaller, respectively. > > Though now that I think about it, I wonder how the > getAttachmentAsByteArray() is handled, given that I'd think this would > be called during unmarshalling - is there buffering of the input stream > going on? Kohsuke, can you comment on this? > > - Dennis > > Glen Daniels wrote: > > > ...attached. Discussed Dennis' proposal for AXIOM refactoring to > > enable lower-level MTOM support for DB frameworks. We got to > > consensus on the receiving side, but didn't have a chance to finish > > discussing the sending side, which we hope to do via email ASAP. > > > > --Glen > > -- "May the SourcE be with u" http://webservices.apache.org/~thilina/ http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
