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: axis-user@ws.apache.org >> 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: axis-user@ws.apache.org >> > 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]
