cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Tooling, Code First Approach & Service Model
Date Tue, 29 Aug 2006 04:10:05 GMT
James Mao wrote:

>Dan Diephouse 写道:
>  
>
>>James Mao wrote:
>>
>>  
>>    
>>
>>>Hi Dan,
>>> 
>>>
>>>    
>>>      
>>>
>>>>Its a requirement. XFire supports it and we need a migration path for
>>>>users using XMLBeans. XMLBeans provides access to the DOM underneath,
>>>>which a lot of people like. Or take JiBX. It is about 2x faster than
>>>>JAXB. There are a lot of pros and cons to the different databinding
>>>>toolkits. Which one you use really depends on your situation.
>>>> 
>>>>   
>>>>
>>>>      
>>>>        
>>>>
>>>I mean the tools works fine with jaxb, and currently i don't think that
>>>we need to support all the databindings.
>>>There are tons of databinding implementation out there[1], and there
>>>will have more new databindings emerging .
>>>Are we going to support all of those databindings? and Why the user need
>>>to care which databinding they are using?
>>>
>>>Maybe it's true for rt, but for the tools i think we just keep the
>>>current design.
>>>
>>>I agreed that there are some duplicate code in the rt and tools, and we
>>>can reuse some of the code and put it into common module.
>>>So, i mean what we need is just refactoring to use the common code, not
>>>re-design to support the multiple databindings.
>>>
>>>Agree?
>>>
>>>
>>> 
>>>
>>>    
>>>      
>>>
>>No, I strongly disagree. Have you ever used the other databindings? Each
>>one hsa its own ups and downs. Did you see how in the bindmark
>>benchmarks JiBX was twice as fast? And what happens if you need to
>>access the XML infoset during parsing? Will JAXB cut it? No. But
>>XMLBeans will.
>>
>>Yes, there are tons of databinding implementations out there, and this
>>is exactly the reason we should have hooks to support them.
>>
>>- Dan
>>  
>>    
>>
>Hi Dan,
>
>I agreed that for the RT, the performance is important, but it's not
>true for the tools,
>Tools work fine with JAXB, i didn't see any performance issues with JAXB
>in tools, and users also didn't report any performance issues so far.
>Have u met the performance issue with Celtixfire tools?
>
>  
>

The point is that a user should be able to generate a service from WSDL
and use another databinding in the service class. So instead of jaxb
generated beans, the generated service will use XMLBeans. Or whatever
toolkit they want. They can't reuse the generated JAXB benas. Each
toolkit has to generate its own beans. To do this, wsdl2java needs to
support the plugable databindings, and the logical way to do that is to
reuse the Databinding support classes we've written. So yes, if a user
generates a service using wsdl2java using the JAXB toolkit, it won't be
as fast as if they generated it using the JiBX toolkit. And if we
generate a service using JAXB, that means they won't have access to the
xml infoset, like they would if it was generated with XMLBeans.

- Dan

-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message