You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2006/03/26 10:10:20 UTC
[Axis2] Databinding structuring proposal
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
--
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Re: [Axis2] Databinding structuring proposal
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
No worries, Ajith - I think it's generally more useful to look at the
actual documents than the schemas, anyway.
- Dennis
Ajith Ranabahu wrote:
>Hi Dennis,
>Not publishing the schema's for the codegen XML's is my fault
>actually. Since things were modified rapidly in the first stages, I
>wanted to wait until things are stable. But it slipped my mind.
>I'll add the necessary schema's soon.
>
>Ajith
>
>On 3/30/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
>
>>Chuck Williams wrote:
>>
>>
>>
>>>"Ajith Ranabahu" <aj...@gmail.com> wrote on 03/29/2006
>>>07:37:48 AM:
>>>
>>>
>>>
>>>>I'm not familiar with the velocity or freemarker template languages
>>>>but In any case I guess we'll be introducing another dependancy! Also
>>>>if we special case the templating language, it makes things harder
>>>>for the people who would need to tweak the code generator.
>>>>
>>>>
>>>>
>>>>
>>>As someone who's tweaked the code generator to add support for choice
>>>particles, recursive data types, etc., I'd like to second Ajith's
>>>point. Xsl is a broadly known syntax that works well for the
>>>generation of final Java code. Having the code generator structured
>>>as it is now, creating a POJO representation of the schema,
>>>transforming that into a DOM, and then using xsl to transform the DOM
>>>into Java classes, is clean, easy to understand, and quite flexible.
>>>
>>>
>>I'm somewhat less thrilled by the use of XSLT for code generation, but
>>passing data in XML is certainly a plus. Overall I found the code
>>generation structure very flexible and easy to extend. I didn't find any
>>documentation of the actual XML formats, though, so I added debug
>>logging of the XML documents used for code generation in
>>MultiLanguageClientEmitter to simplify understanding the existing XSLTs.
>>
>> - Dennis
>>
>>
>>
>
>
>--
>Ajith Ranabahu
>
>
>
Re: [Axis2] Databinding structuring proposal
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Dennis,
Not publishing the schema's for the codegen XML's is my fault
actually. Since things were modified rapidly in the first stages, I
wanted to wait until things are stable. But it slipped my mind.
I'll add the necessary schema's soon.
Ajith
On 3/30/06, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Chuck Williams wrote:
>
> > "Ajith Ranabahu" <aj...@gmail.com> wrote on 03/29/2006
> > 07:37:48 AM:
> >
> >>I'm not familiar with the velocity or freemarker template languages
> >>but In any case I guess we'll be introducing another dependancy! Also
> >>if we special case the templating language, it makes things harder
> >>for the people who would need to tweak the code generator.
> >>
> >>
> >
> > As someone who's tweaked the code generator to add support for choice
> > particles, recursive data types, etc., I'd like to second Ajith's
> > point. Xsl is a broadly known syntax that works well for the
> > generation of final Java code. Having the code generator structured
> > as it is now, creating a POJO representation of the schema,
> > transforming that into a DOM, and then using xsl to transform the DOM
> > into Java classes, is clean, easy to understand, and quite flexible.
>
> I'm somewhat less thrilled by the use of XSLT for code generation, but
> passing data in XML is certainly a plus. Overall I found the code
> generation structure very flexible and easy to extend. I didn't find any
> documentation of the actual XML formats, though, so I added debug
> logging of the XML documents used for code generation in
> MultiLanguageClientEmitter to simplify understanding the existing XSLTs.
>
> - Dennis
>
--
Ajith Ranabahu
Re: [Axis2] Databinding structuring proposal
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Chuck Williams wrote:
> "Ajith Ranabahu" <aj...@gmail.com> wrote on 03/29/2006
> 07:37:48 AM:
>
>>I'm not familiar with the velocity or freemarker template languages
>>but In any case I guess we'll be introducing another dependancy! Also
>>if we special case the templating language, it makes things harder
>>for the people who would need to tweak the code generator.
>>
>>
>
> As someone who's tweaked the code generator to add support for choice
> particles, recursive data types, etc., I'd like to second Ajith's
> point. Xsl is a broadly known syntax that works well for the
> generation of final Java code. Having the code generator structured
> as it is now, creating a POJO representation of the schema,
> transforming that into a DOM, and then using xsl to transform the DOM
> into Java classes, is clean, easy to understand, and quite flexible.
I'm somewhat less thrilled by the use of XSLT for code generation, but
passing data in XML is certainly a plus. Overall I found the code
generation structure very flexible and easy to extend. I didn't find any
documentation of the actual XML formats, though, so I added debug
logging of the XML documents used for code generation in
MultiLanguageClientEmitter to simplify understanding the existing XSLTs.
- Dennis
Re: [Axis2] Databinding structuring proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-03-29 at 09:28 -1000, Chuck Williams wrote:
> >
> As someone who's tweaked the code generator to add support for choice
> particles, recursive data types, etc., I'd like to second Ajith's
> point. Xsl is a broadly known syntax that works well for the
> generation of final Java code. Having the code generator structured
> as it is now, creating a POJO representation of the schema,
> transforming that into a DOM, and then using xsl to transform the DOM
> into Java classes, is clean, easy to understand, and quite flexible.
> I was able to read and understand the code, and then extend it with
> the features we needed, in about a day while learning axis2. That
> would likely not have been possible if a more specialized and
> unfamiliar templating language was used.
Most definitely +1 Chuck .. hope you continue to contrib so we can bring
you in as a committer!
Sanjiva.
Re: [Axis2] Databinding structuring proposal
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi Kenneth,
See my comments inline
>
> +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'm +1 on that too. We should have a mechanism where the codegen can
live without any of the extensions. I think we can figure out a
reflection based way to load the classes
> 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)?
Well, I think I'm the one who convinced the others to use XSLT and
here are the reasons behind it as I see.
1. XSLT is a fairly known syntax to write templates in so it should be
easier for
most of the people
2. JRE (1.4 upwards) comes bundled with XML/XSL processing libraries
(Crimson|Xerces|Xalan) so we are not inventing any third party
dependancies
> would have been more straightforward to use a straight POJO-based
> input model into a template lang like velocity or freemarker.
I'm not familiar with the velocity or freemarker template languages
but In any case I guess we'll be introducing another dependancy! Also
if we special case the templating language, it makes things harder
for the people who would need to tweak the code generator.
--
Ajith Ranabahu
Re: [Axis2] Databinding structuring proposal
Posted by Kenneth Tam <ke...@gmail.com>.
On 3/26/06, Dennis Sosnoski <dm...@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.
Re: [Axis2] Databinding structuring proposal
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
>>>
>>>
>>>
>
>
>
Re: [Axis2] Databinding structuring proposal
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+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
> >
Re: [Axis2] Databinding structuring proposal
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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
>