irst approach as it seems cleaner for me. Its
> the same thing we do to connect data in to OMElement. And it nicely and
> elegantly fit in to the differed building approach. This approach is
> almost implemented for ADB (Axis2 Data Binding).
>
> Well the problem in that approach is that
First approach looks much cleaner. I am bit fuzzy about how the second
approach would affect our MTOM architecture. I mean how can we be
aware of xop if we are not aware of the events.
Thilina, you wanna comment on that??
>
> 1. Getting pull parser from the data bound object, irrespective of wh
Hi,
First of all I'm not sure about the any of the frameworks supporting MTOM/XOP.
IMHO if somebody wants to have MTOM with data binding, there will be issues with both these approaches.In the first approach we are giving the StaxOMBuilder an pull parser. Given a pull parser even though it throws
nect data in to OMElement. And it nicely and
elegantly fit in to the differed building approach. This approach is
almost implemented for ADB (Axis2 Data Binding).
Well the problem in that approach is that (thanks to Dennis for
pointing), JAXB, JiXB do not have a way of getting a pull parser. But
On Mon, 2005-10-31 at 16:56 -0800, Eric Johnson wrote:
>
> The fundamental point, though, is that a bean need not have its own
> serialization code - it can be "dumb" to how it actually gets
> serialized. If you take that approach, the above question as to whether
> you're using a "writer" or
Sanjiva Weerawarana wrote:
On Mon, 2005-10-31 at 16:56 -0800, Eric Johnson wrote:
The fundamental point, though, is that a bean need not have its own
serialization code - it can be "dumb" to how it actually gets
serialized. If you take that approach, the above question as to whether
you'r
Eric Johnson wrote:
> Eran Chinthaka wrote:
>
>> Steve Loughran wrote:
>>
>>
>>
>>> On the subject of data binding, it would suit me nicely if you could
>>> easily build an OMElement graph from a DOM or SAX tree.
>>>
>>
> I believe there is a "SAX" builder for AXIOM trees. I don't think
>
Eran Chinthaka wrote:
So merging all the discussions, the argument biols down to who has the
control. So I can provide a method in ADBPullParser, so that you can do
some thing like this.
ADBPullParser adbPullParser = new ADBPullParser(qName, propertyList,
attributeList);
adbPullParser.seriali
AFAIK the actual JAXB 2.0 specification and RI are still covered by
licenses which prohibit public discussions of the API information
disclosed under those licenses. However, a search finds unrestricted
pages such as
https://jax-rpc.dev.java.net/jaxws20-ea2/docs/mtom-swaref.html which
discuss
Hi,
Im interested in finding out what people are
expecting from axis2 when it comes to data binding.
Until yesterday I was thinking (this may sound naive)
that we would select a particular data-binding tool at
the time we generate code and then thats it
the
generated code would be tightly coupl
I recently made some changes (going into JiBX RC1) to support using JiBX
with SOAP. These are primarily designed around what I've found was
necessary for JibxSoap, but I'm also planning to hook into Axis2 and the
same requirements are likely to apply there. I know the 0.9 version has
XmlBeans s
Hi all,
Today I saw that we have a new and separate module for data binding. But
If I remember correct, we were thinking of putting our data binding
stuff under the XML module. That was one of the reason behind renaming
the module om in to xml.
Comments ??
Hi all,
I'm trying to integrate the new (our own) databinding framework with
the Axis2 code generator. However I find it difficult to figure out
where the generators are!
Anyone (most probably Glen) can give me a hint as to where I should start looking ?-- Ajith Ranabahu
se comment)
I personally prefer the first approach as it seems cleaner for me. Its
the same thing we do to connect data in to OMElement. And it nicely and
elegantly fit in to the differed building approach. This approach is
almost implemented for ADB (Axis2 Data Binding).
Well the problem in that ap
Hello Dennis,
The internals of the Databinding framework are as follows
1. We have something called extensions that run before the actual
code generator. For XMLBeans we have an extension that takes the
Schema element from the WSDL file and feeds it into the XB schema
parser. The logic of XB is
Hi Ajith,
Sounds great on the data binding support! I'll check it out within the
next couple of weeks. JiBX currently uses XMLPull for input, but I can
probably implement a simple wrapper for converting between the Axis StAX
parser and an XMLPull API. Are you listening, Alek - any comments? Th
Hi,
>data binding framework to pass back information about the> blobs to be sent as attachments, and to access the attachments when> unmarshalling.
IMHO this is doable with the way Axis2 currently handles MTOM. We use OMText to hold the binary data and act as the blob. There are several states t
Thilina Gunarathne wrote:
IMHO this is doable with the way Axis2 currently handles MTOM. We use
OMText to hold the binary data and act as the blob. There are several
states to OMText, which can be set using "is Binary" and
"isOptimised" attributes. When OMText contains binary data (either as
Hi folks:
Please check out http://www.w3.org/TR/xml-media-types/
This document describes runtime and design time attributes to indicate
media types for base64 (and therefore potentially optimized) content.
When we see these annotations in schema, we should have the ability to
default to optim
Dennis Sosnoski wrote:
Hi Ajith,
Sounds great on the data binding support! I'll check it out within the
next couple of weeks. JiBX currently uses XMLPull for input, but I can
probably implement a simple wrapper for converting between the Axis
StAX parser and an XMLPull API. Are you listening
-0...let's please keep it separate.
-- dims
On 9/8/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Today I saw that we have a new and separate module for data binding. But
> If I remember correct, we were thinking of putting our data binding
> stuff under the XML module. That was one
Hi Eran!
Eran Chinthaka wrote:
Hi all,
Today I saw that we have a new and separate module for data binding. But
If I remember correct, we were thinking of putting our data binding
stuff under the XML module. That was one of the reason behind renaming
the module om in to xml.
Comments ??
i usually find it easy to merge two things than take them apart. If it
is working now and there is no pressing need...do we really need one
module?
-- dims
On 9/8/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> Hi Eran!
>
> Eran Chinthaka wrote:
> > Hi all,
> >
> > Today I saw that we have a new a
Hi dims:
i usually find it easy to merge two things than take them apart. If it
is working now and there is no pressing need...do we really need one
module?
Nope. Easy enough either way.
--G
+1 for keeping it separate until proven otherwise ..
Sanjiva.
On Thu, 2005-09-08 at 08:29 -0400, Davanum Srinivas wrote:
> i usually find it easy to merge two things than take them apart. If it
> is working now and there is no pressing need...do we really need one
> module?
>
> -- dims
>
> On 9
Ohh seems like my mail has started a mess here.
Anyway, What I did was just reminded you all genious that we did a
refactoring to enable data binding in to XML module. I didn't say that
it *should* come.
Anyway, I also agree with Dims that its easy to merge things rather than
taking them apa
Ajith Ranabahu wrote:
Hi all,
I'm trying to integrate the new (our own) databinding framework with the
Axis2 code generator. However I find it difficult to figure out where the
generators are!
Anyone (most probably Glen) can give me a hint as to where I should start
looking ?
Hi Ajith!
I o
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
Axis2 data binding on all Axis 1.x doc/lit WSDLs
Key: AXIS2-213
URL: http://issues.apache.org/jira/browse/AXIS2-213
Project: Apache Axis 2.0 (Axis2)
Type: Wish
Components: databinding
Reporter: Eran Chinthaka
[ http://issues.apache.org/jira/browse/AXIS2-213?page=all ]
Eran Chinthaka reassigned AXIS2-213:
Assign To: Ajith Harshana Ranabahu
> Axis2 data binding on all Axis 1.x doc/lit WS
Note however that the codegen fails to work on DIME based wsdl's
> Axis2 data binding on all Axis 1.x doc/lit WSDLs
>
>
> Key: AXIS2-213
> URL: http://issues.apache.org/jira/browse/AXIS2-213
> Pro
47 matches
Mail list logo
