Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.mao@iona.com designates
 63.65.132.112 as permitted sender)
Message-ID: <44F3B892.80100@iona.com>
Date: Tue, 29 Aug 2006 11:46:26 +0800
From: James Mao <james.mao@iona.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Tooling, Code First Approach & Service Model
References: <NJEGKBFJCOPBPCAHACGLMEPECJAA.jim.ma@iona.com>
 <44F2BE39.9030103@iona.com> <44F31C88.20006@envoisolutions.com>
In-Reply-To: <44F31C88.20006@envoisolutions.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit

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?

[1] https://bindmark.dev.java.net/

Cheers,
James.