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:

[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 ?