axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Tam" <kentamina...@gmail.com>
Subject Re: [Axis2] Databinding structuring proposal
Date Tue, 28 Mar 2006 08:24:00 GMT
On 3/26/06, Dennis Sosnoski <dms@sosnoski.com> wrote:
> I've got the initial JiBX data binding support ready to drop into Axis2.
> I'd like to propose a somewhat different structure for this, though,
> with the intent that the other data binding approaches supported also
> implement the same sort of structure.
...
>
> binding framework to be used. That way the JiBX jars are only needed
> when JiBX is actually being used, which seems like the way we want
> things to work. If this approach is adopted for all the data binding
> frameworks we can make all the framework code optional components for
> the code generation rather than requiring more and more of these
> framework jars to be included in the distribution. So a user could
> download a minimal distribution which only included Axiom code
> generation support (since Axiom is embedded throughout the whole Axis2
> framework anyway), or distributions for each individual data binding
> framework. Alternatively, the data binding framework support could be
> just a separate zip that users would then unzip into their minimal
> distribution - that way JAXB 2.0 could be handled with a separate
> download that's not part of the Apache project, for instance.
>
> Discussion, anyone?

+1 to more decoupling from binding frameworks -- I'd very much like to
be able to use the latest JAXB RI with Axis2, and we're already seeing
sufficient proliferation of binding frameworks that it seems like it
makes a lot of sense to go to a model where the code [many|most|all
but ADB] is optional.

I need to grok the way the current code-gen process manages multiple
bindings a little deeper before I have any specific suggestions..
though I do have some questions -- can anyone elaborate a bit on the
design decision behind basing the code-gen process on XSLT  (and thus
representing the input WSDL info model as a DOM)?  It seems like it
would have been more straightforward to use a straight POJO-based
input model into a template lang like velocity or freemarker.

Mime
View raw message