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
