Again, I think sometimes thinking out of the box is what is really needed,
your understanding of VTD-XML seems limited... In our previous discussion,
I have provided explanations to many of your questions....hope they made
sense
to you...
concerning your remarks on VTD-XML modification feature, here is a link that
might interest people in this mailing list
http://www.javaworld.com/javaworld/jw-07-2006/jw-0724-vtdxml.html
----- Original Message -----
From: "Dennis Sosnoski" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, August 19, 2006 5:31 PM
Subject: Re: [Axis2] Reading POJOs at client side
We've discussed VTD previously, on the Seattle Java users group list.
Since that list isn't public I'll repeat my main points here.
VTD is basically an indexing schema that stores offsets into the document
for XML components. I see this as of limited usefulness for most
developers, who generally only want to work with a document one time,
rather than going through the same document repeatedly. Since both the
entire document text and the constructed index are stored in memory, the
memory usage is generally considerably higher than what you have with a
data binding approach (let alone an approach that processes data on the
fly). VTD is also read-only, and cannot be used to modify or create XML
documents, unlike data binding and document model approaches.
Leaving aside the limitations of VTD, the "benchmarks" given on the site
are deceptive. You only time your indexing of the documents, not any
retrieval of the data; in order to actually do anything with the data in
the documents you'd have to run through a separate retrieval. The time for
SAX/StAX, on the other hand, includes providing the data to the
application. I pointed this out to you several months ago and you have
neither changed the benchmarks nor added any comment about this
difference.
As I said before, I do think the VTD approach has very interesting
potential. There are many situations where a reasonably compact, indexed,
data store for XML documents could come in really useful - for instance,
in handling encryption and signing, where a full document model of the
data otherwise needs to be constructed. But to be usable for this purpose
VTD would need StAX event stream reader/writer (where the reader would
just access data out of VTD, and the writer would generate VTD with
indexing) and canonicalization support, along with the ability to replace
portions of the document. I see similar issues with other potential use
cases for VTD - the requirement that everything be stored in memory makes
it useless for very large documents, and the fixed maximum sizes on
documents, names, prefixes, and nesting levels are all potential problems
for many applications. I personally wish you'd focus on redesigning VTD to
get around some of these limitations.
- Dennis
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Jimmy Zhang wrote:
Working with a generic XML Document tree model isn't necessarily slow
http://vtd-xml.sf.net/
Object binding maybe easy to use but it makes the applications too
tightly coupled,
when data format evolves, object binding tends to break applications...
----- Original Message ----- From: "Dennis Sosnoski" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 18, 2006 2:44 PM
Subject: Re: [Axis2] Reading POJOs at client side
Even reflection-based data binding can be faster than working with
object models - but in this case, it looks like the BeanUtil code used
for the conversions is building the tree in any case, rather than
working directly with the parser. It also looks like it builds the
reflection metadata every time through. So I suspect you're right that
working directly with OM is going to be much faster than using this.
Performance aside, I'd think the programming advantages of working with
classes rather than directly manipulating a document model would be a
more important concern for most users. If they really need speed they're
much better off using ADB or JiBX for the conversions to and from XML.
JiBX is certainly much faster than using OM, and lets users work with
their existing POJOs.
- Dennis
robert lazarski wrote:
Performance advantages in the context of OM and Stax versus the axis2
implementation of RPC and arrays, as the OP wanted ? AFAIK that case
has not been thrown against jmeter but my hunch is that OM and Stax
will run circles around anything involving the reflection based
RPCMessageReceiver. If you think otherwise I suppose we could agree to
a test case and do the pepsi challenge via jmeter ;-) . I'd be happy
to stand corrected.
Cheers,
Robert
http://www.braziloutsource.com
On 8/18/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
What kind of performance advantages are you talking about, Robert?
AFAIK
the only way OM has any performance advantage is if it's not fully
built
(i.e., when it's used in conjunction with data binding, where the data
binding handles actual data conversions to and from objects).
Otherwise,
it's just a somewhat heavy-weight document model.
- Dennis
robert lazarski wrote:
> OM has lots of performance advantages among many others so go with
> that if in doubt.
>
> HTH,
> Robert
> http://www.braziloutsource.com
>
> On 8/18/06, Charak, Vikas <[EMAIL PROTECTED]> wrote:
>> I guess, I am still trying to find out for interoperability
reasons or
>> what is recommended way .If I should be using OMElement as input
and
>> output for my methods [raw xml format] or should it be more
structured
>> like using POJO etc.?
>> The one issue I see with RawXml is generating XML using OMElement's
>> API's where as I can easily create POJOs from my data.
>> Any recommendations.
>>
>>
>> -----Original Message-----
>> From: robert lazarski [mailto:[EMAIL PROTECTED]
>> Sent: Friday, August 18, 2006 2:51 PM
>> To: [email protected]
>> Subject: Re: [Axis2] Reading POJOs at client side
>>
>> AFAIK RPCMessageReceiver just follows the old jax-rpc JSR much
in the
>> way axis 1.x does , and the integration tests reflect that. So if
you
>> find a problem file a jira but I do expect that you can use these
>> examples between languages.
>>
>> HTH,
>> Robert
>> http://www.braziloutsource.com/
>>
>> On 8/18/06, Charak, Vikas <[EMAIL PROTECTED]> wrote:
>> > I might be wrong. This will work if client is a Java Client. What
>> > happens if the client is non-java, then is this way
recommended or
>> > should I be using OMElement as input and output for my method.
[Data
>> > goes in and out only in raw xml format]
>> >
>> > Any suggestions?
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: robert lazarski [mailto:[EMAIL PROTECTED]
>> > Sent: Friday, August 18, 2006 1:16 PM
>> > To: [email protected]
>> > Subject: Re: [Axis2] Reading POJOs at client side
>> >
>> > In the latest source there is some integration tests:
>> >
>> > modules/integration/test/org/apache/axis2/rpc/RPCCallTest.java
>> >
>> > That has some array examples and should get you started.
>> >
>> > HTH,
>> > Robert
>> > http://www.braziloutsource.com/
>> >
>> > On 8/18/06, Charak, Vikas <[EMAIL PROTECTED]> wrote:
>> > > Using RPCMessageReceiver I was able pass person POJO to my
client
>> from
>> > a
>> > > web service
>> > >
>> > > public User[] getUsers() {
>> > > return User array;
>> > > }
>> > >
>> > > Now I have ,
>> > >
>> > > public void addUsers(User[]) {
>> > > }
>> > >
>> > > Any idea on writing a java client to send user arrays to
addUsers
>> > method
>> > > of the same web service. User is a plain java class with
getters and
>> > > setters.
>> > >
>> > > Any help is appreciated.
>> > >
>> > >
>> > > Thanks.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
