Hi dims:
May be i am missing something...the difference in my mind is a person
implementing a databinding layer should be able to access the
attachements without having to build the om tree. straight from stax
to java objects with no om and use whatever they need to store the
attachments byte ar
On Fri, 2006-03-31 at 09:52 -0500, Glen Daniels wrote:
> Hi dims:
>
> > May be i am missing something...the difference in my mind is a person
> > implementing a databinding layer should be able to access the
> > attachements without having to build the om tree. straight from stax
> > to java objec
Sanjiva,
/me scratches his head and wonders How come glen understands what he
says - "exactly what dims describes here" and sanjiva doesn't :)
Let me try again...The DB framework will build the java objects
directly from the MIME root part (this is the first step always!) and
*then* accesses the
On Fri, 2006-03-31 at 10:55 -0500, Davanum Srinivas wrote:
> Let me try again...The DB framework will build the java objects
> directly from the MIME root part (this is the first step always!) and
> *then* accesses the other mime parts and sticks them where it is
> needed (or adds a reference) on t
if ws-sec is turned on, then we force a build of the om tree...just
like we do now.
-- dims
On 3/31/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
> On Fri, 2006-03-31 at 10:55 -0500, Davanum Srinivas wrote:
> > Let me try again...The DB framework will build the java objects
> > directly from
Ah, that makes sense. It does seem to create potential problems, though,
since it relies on the data magically appearing in the byte[] (or in the
case of an unknown size, the byte[] object itself magically appearing)
sometime after the initial unmarshalling. With an DataHandler you can at
least
Yes, I think that's the crux of the matter - we need to be able to build
a tree *if required* by ws-sec or such, but the common case is no ws-sec
and hence no tree needed. And if you *do* use ws-sec, the OM
tree-building is the least of your performance concerns.
For the JiBX interface to Axis
Hey Sanjiva:
On Fri, 2006-03-31 at 10:55 -0500, Davanum Srinivas wrote:
Let me try again...The DB framework will build the java objects
directly from the MIME root part (this is the first step always!) and
*then* accesses the other mime parts and sticks them where it is
needed (or adds a refere
Thilina Gunarathne wrote:
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
Hi Thilina,
I agree that buffering the actual SOAP message body text in the case of
attachments is fine, at least until we see some reason to change. If
somebody's using attachments hopefully the SOAP message body is not
going to be huge and buffering it will not add a lot of overhead. The
ac
A quick comment before I run for my lecture :)
> > What you're looking at is SwA .. MTOM is not that IMO.
>
> Same deal for either really, just in one case you have hrefs and in
> another you have xop:Includes.
>
There's a huge difference.. SwA results in two data models. One for
the XML and other
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.
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 inter
On Fri, 2006-03-31 at 15:35 +0600, Thilina Gunarathne wrote:
>
> 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
>
>
> IMHO we are doing the exactly the same thing using OMTexts.. Currently
> we are doing this wit
Sanjiva,
May be i am missing something...the difference in my mind is a person
implementing a databinding layer should be able to access the
attachements without having to build the om tree. straight from stax
to java objects with no om and use whatever they need to store the
attachments byte arra
Hi,
> May be i am missing something...the difference in my mind is a person
> implementing a databinding layer should be able to access the
> attachements without having to build the om tree. straight from stax
> to java objects with no om and use whatever they need to store the
> attachments byte
Hi,
I'm thinking of Buffering the stream containing the SOAP envelope only
when someone actually refering to the attachment..
> While that's interesting in theory, whoever sent the attachment more
> often than not expected the other end to read the darn thing. I don't
> see the point of that pote
17 matches
Mail list logo
