[Axis2] JAX-B RI databinding support

[Kenneth Tam <ke...@gmail.com>]

Hi folks,

I just submitted a patch that adds support for the JAX-B RI binding
framework (http://issues.apache.org/jira/browse/AXIS2-660), following
this reflection-based approach -- would appreciate some committer eyes
on it.

thanks,
k

On 3/28/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Yes, using reflection was my thought, too. I'll go ahead and change to
> JiBX code to implement this fully, then look at doing the same for
> XMLBeans and ADB. Hopefully those working on other frameworks (JaxMe,
> etc.) can follow along.
>
>   - Dennis
>
> Sanjiva Weerawarana wrote:
>
> >+1 for the approach Dennis. Can you do the changes please? Ideally we
> >should use reflection to use the appropriate data binding module so that
> >there's no compile time dependency for the overall framework on
> >anything. The default (Axiom) can be there of course.
> >
> >Sanjiva.
> >
> >On Sun, 2006-03-26 at 20:42 +1200, Dennis Sosnoski wrote:
> >
> >
> >>One correction - you don't get an error on code generation if the jars
> >>for a framework you're not using are missing from the classpath. I
> >>thought I'd seen that on an earlier version, but I've verified it
> >>doesn't happen now. I do still think a module approach per data binding
> >>framework would be cleaner, though.
> >>
> >>  - Dennis
> >>
> >>Dennis Sosnoski 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.
> >>>
> >>>Right now the codegen module knows about all the possible data binding
> >>>extensions and loads them all as part of the initial setup. It calls
> >>>each one in turn, allowing each extension to decide for itself whether
> >>>it needs to do anything. In and of itself I think this is good. What
> >>>becomes a problem is that each extension typically includes code that
> >>>links into the individual data binding framework, which means all of
> >>>these frameworks need to be present in order for the codegen to
> >>>execute. For example, if you delete the xbean-2.1.0.jar from the lib
> >>>you'll get an error trying to do code generation even if you're not
> >>>using XMLBeans. As more and more data binding frameworks are supported
> >>>this is going to create increasing problems (including the licensing
> >>>issues for JAXB 2.0, as mentioned in some separate recent threads).
> >>>
> >>>What I'd like to do for JiBX is add a separate module containing the
> >>>code that's tied to JiBX, then load that code dynamically from the
> >>>JiBX data binding extension - but only if JiBX is actually chosen as
> >>>the data 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?
> >>>
> >>> - Dennis
> >>>
> >>>
> >>>
> >
> >
> >
>