summary: today discussion was about the current data binding framework in Axis2
please make sure to visit and add topics to agenda for next week chat at: http://wiki.apache.org/ws/ChatAgenda
[22:28] <dims> Hi dennis, eran [22:28] <Chinthaka> hi all [22:28] <Chinthaka> seems I'm late, I forgot it :( [22:28] <dims> dennis: would appreciate feedback and patches for the Axis Data Binding :) [22:28] <dsosnoski> I did too - and this is the week when I'm actually awake for the chat! [22:28] <dsosnoski> I've been behind on the email list, dims [22:29] <dsosnoski> I noticed some discussion on the Axis Data Binding topic - will catch up on these and see what's up [22:29] <Chinthaka> I know its very difficult to be up to date with the high traffic ;) [22:29] <dsosnoski> Just too much else going on... (including moving to New Zealand) [22:31] * chamil has joined #apache-axis [22:35] <dsosnoski> On the "simple" data binding topic, I agree with Eran ;) [22:35] <dsosnoski> It's cleaner to have beans write themselves to a supplied XMLStreamWriter [22:35] <dims> yes [22:36] <dsosnoski> Same discussion we've had before on the mailing list [22:37] <dsosnoski> Whoops - guess I meant I agreed with Eric Johnson, not with Eran :( [22:39] * sanjiva has joined #apache-axis [22:39] <dsosnoski> Anyone going to participate in the Microsoft WCF Interop? [22:39] <Chinthaka> Dennis : did you look at the ADBPullParser code [22:40] <Chinthaka> Personaly I like the way of getting a pull parser from a bean [22:40] <dsosnoski> Nope, haven't checked latest changes [22:40] <Chinthaka> and not asking him to write himself [22:40] <Chinthaka> the reason is, then only you will get the differed building support [22:40] <dsosnoski> I agree getting a parser from the bean is more elegant [22:41] <dsosnoski> Won't work well with most data binding frameworks, though [22:41] <Chinthaka> exactly. So y didn't u like it [22:41] <dsosnoski> Including JAXB, JiBX, etc. XMLBeans is really the only one that does this [22:41] <Chinthaka> I don't think so [22:41] <dsosnoski> and it cheats ;) by keeping everything as XML internally [22:41] <Chinthaka> shall I explain ? [22:42] <dsosnoski> Yes, please do [22:42] <Chinthaka> or do u want me to explain ? [22:42] <Chinthaka> ok. [22:42] <Chinthaka> I think we can get a SAX Output from *any* of the data bound objects [22:42] <Chinthaka> irrespective of the db framework that is being used [22:43] <Chinthaka> so if we have a SAX -> StAX converter, which is not that difficult to write [22:43] <Chinthaka> we can do the same thing as we do with ADBPullParser [22:44] <dsosnoski> Agreed, but that means buffering the events and feeding them back out [22:44] <dsosnoski> through the pull parser [22:44] <dsosnoski> It'll work, but the performance is going to take a substantial hit [22:44] <Chinthaka> well, if your data binding framework doesn't have a pull interface u r not gaining that much [22:45] <Chinthaka> my opinion is to make at least some cases fast by not doing anything bad to the others [22:45] <Chinthaka> that means, if u r using ADB or XMLBeans [22:45] <dsosnoski> JAXB and JiBX 1.1 will write to XMLStreamWriter directly [22:45] <dsosnoski> XMLBeans will, too [22:46] <dsosnoski> It seems like that's the form of output to support [22:46] <Chinthaka> Dennis : if JAXB and JiBX has the ability to write to XSR, why are n [22:47] <Chinthaka> why aren't they giving a pull interface [22:47] <Chinthaka> well all in all, this is a questions of elegance and who has the control [22:47] <Chinthaka> so we have to decide on one approach [22:48] <dsosnoski> No pull interface because this would invert the internal processing - [22:48] <dsosnoski> you need to track where you are in the structure so you know what event [22:48] <dsosnoski> to generate next [22:48] <Chinthaka> FYI : We are almost done with ADBPullParser for XMLBeans gen'ed stuff and ADB [22:48] <dsosnoski> Gets very messy (unless you're keeping everything as XML anyway, [22:48] <dsosnoski> as with XMLBeans) [22:49] <Chinthaka> oic [22:49] <Chinthaka> plus one more thing [22:51] <Chinthaka> when we are using OM, we got used to get a pull parser from it and consume it [22:51] <Chinthaka> ( but we can ask OM to serialize itself too) [22:51] <Chinthaka> so if we want to make the approach consistent [22:52] <Chinthaka> I prefer to get a pull parser from any SOAPEnvelope and serialize that [22:52] <Chinthaka> which means from all the data bound object which are hanging under the SOAPBody, will need to provide a pull interface [22:54] <dsosnoski> Well, XSR approach is also cleaner for streaming output [22:54] <dsosnoski> you just write directly to the stream - if you get a parser, you have to copy [22:54] <dsosnoski> Here again, there's likely to be a noticable performance difference [22:55] <dsosnoski> I guess a lot depends on how important performance is to Axis2 goals [22:55] <Chinthaka> Performance is one of the key things in Axis2 [22:55] <dsosnoski> Getting data with a pull interface will hurt JAXB/JiBX performance substantially [22:56] <Chinthaka> Dennis : Hang on [22:56] <dsosnoski> I think it'll also hurt performance in general (because of the parser-writer copy step) [22:56] <Chinthaka> the XSR approach will hurt the RPC stuff a bit [22:56] <dsosnoski> but not as much as it'll hurt when using JAXB/JiBX [22:57] <Chinthaka> in current approach, you can give *any* java bean to RPC call and send [22:58] <Chinthaka> ADBPullParser can generate pull events for any java bean [22:58] <Chinthaka> if u can look at the code on RPCCall, u will see that [22:59] * Deepal has joined #apache-axis [22:59] <Chinthaka> Dennis : I didn't understand how JAXB or JiBX will get hurt from this approach [22:59] <Deepal> hi gusy , sorry I forgot abt the chat [22:59] <dsosnoski> The issue is that they only support writing output (not having it read from them) [23:00] <dsosnoski> this means they'll need to use an adapter - the first time the parser is called [23:00] <dsosnoski> it'll generate all the output to a buffer [23:00] <dsosnoski> Then it can read the data from the buffer in response to parse method calls [23:02] <Chinthaka> hmm I think I'm missing something here [23:02] <dsosnoski> Strange, I just did an svn update (first in about a month) [23:02] <Chinthaka> I don't want JAXB to write data in to my buffer using XSR and then [23:02] <Chinthaka> using that buffer to generate events [23:03] <Chinthaka> why what happened with SVN ? [23:03] <dsosnoski> and only got a dozen or so updated/added java files [23:03] <Chinthaka> when did u get the last update ? [23:03] <dsosnoski> I think the last update was around the beginning of this month [23:04] <dsosnoski> guess I'll try a clean co instead [23:04] <Chinthaka> hmm then u should get lots of changes [23:04] <Chinthaka> Axis2 is moving very fast ;) [23:05] <dsosnoski> re:JAXB - if you want an XSR interface for accessing JAXB output, I don't see alternative [23:05] <Chinthaka> no [23:05] <Chinthaka> can i get a SAX outter from JAXB [23:05] <Chinthaka> ? [23:05] <Chinthaka> I think yes [23:06] <dsosnoski> You can write to an XSW with JAXB 2.0 [23:06] <Chinthaka> brb [23:07] <dsosnoski> it'd be pretty easy to have an adapter XSW that wrote SAX events to your handler [23:07] <dsosnoski> what difference does it make? [23:14] <Chinthaka> back [23:15] <Chinthaka> hmm i c a small error in my thinking :( [23:15] <Chinthaka> anyway, let me explain how this getting pull events way fits to Axis2 architecture [23:15] <Chinthaka> any body @ home ? [23:16] <dsosnoski> Still here (but going soon) [23:16] <Chinthaka> the InOutMR (or any one who is putting back data bound stuff) [23:19] <Chinthaka> one can get the databound object [23:19] <Chinthaka> get a pull parser from it and using that create an OMElement [23:20] <Chinthaka> and then hook that up in to the envelope [23:21] <dsosnoski> I understand the elegance of the approach [23:21] <Chinthaka> yes [23:21] <dsosnoski> it just doesn't match the way most data binding frameworks work, though [23:21] <Chinthaka> hmm [23:22] <Chinthaka> ok what sort of generic approach u can think of [23:22] <Chinthaka> ideas [23:22] <dsosnoski> Could keep some of the elegance with a change of direction [23:23] <dsosnoski> define an OMElement class which adapts to a particular DB framework [23:23] <dsosnoski> then when the OMElement is told to write itself to an XSW [23:24] <dsosnoski> it can just pass the XSW on to the DB framework [23:24] <dsosnoski> this is what I was planning for JiBX (and JAXB, at some point) [23:24] <Chinthaka> I did some kind of thing called ObjectToOMWrapper [23:24] <Chinthaka> some time back [23:24] <Chinthaka> seems this is bit similar to that [23:25] <dsosnoski> Sounds like the main difference is just that the customized OMElement [23:25] <Chinthaka> yea [23:25] <dsosnoski> would be directly embedded in OM structure [23:25] <Chinthaka> so how does this fit in to ADB and XMLBeans ? [23:26] <dsosnoski> they could go either way - use this type of adapter OMElement [23:26] <dsosnoski> or just get XSR as now [23:26] <dsosnoski> Got to go for now, can we continue on mailing list? [23:26] <Chinthaka> yes [23:26] <Chinthaka> Good idea [23:27] <Chinthaka> I don;t have the whole chat log [23:27] * dsosnoski has quit IRC ("using sirc version 2.211+KSIRC/1.3.11") [23:27] <Chinthaka> who has it ?