Thanks for the clarification. I am +1 to go ahead Ajith
On Fri, Mar 7, 2008 at 12:29 AM, Chuck Williams <[EMAIL PROTECTED]> wrote: > > Hi Ajith, > > Our person working on Axis2 now, An Hong, has discovered the right fix. > amilas already did all the plumbing for this in r585400, so the code > generator already adds a defaultValue attribute for the property to the xml > bean description that is transformed by ADBBeanTemplate.xsl. The property > is initialized to the correct default in the generated java bean now! > > The problem is that one piece was missed. The parse() method overwrites > with MIN_VALUE (or NaN) the correct default value already in place from > constructing the bean. All that is required is to omit this arbitrary value > defaulting in parse() whenever the @defaultValue attribute exists on the > property. > > This is a simple change. An is testing it now and will open a jira with > the patch. > > Hope all is well with you! > > Chuck > > > Ajith Ranabahu wrote on 03/06/2008 05:06 PM: > > Hi Chuck, > > Does it mean that ADB does not populate the correct default value > (supplied in the schema) ? Or is it just that it defaults to a random > (unpredictable) value ? > > if its the latter I think we can easily provide a fix for that. The > former (which I think may even be treated as a bug) however would > require some effort > > Ajith > > On Thu, Mar 6, 2008 at 9:06 PM, Chuck Williams <[EMAIL PROTECTED]> wrote: > > > Hi All, > > It's been a long time. We are trying to upgrade to the latest Axis2 and > have run into a serious issue. Axis2 now uses various MIN_VALUE's and > NaN's as the marker for unset values in ADB binding code, rather than > the previous behavior of using 0. > > Our server needs to either have wsdl-declared defaults used, which axis2 > adb message parsing code does not do, or to implement its own > defaulting, which is what it has been doing. However, testing for the > specific axis2 implementation market for unset values, e.g. > Integer.MIN_VALUE, to discover a parameter has not been set seems too > hackish. > > A simple solution would be to add a new method to the automatically > generated ADB binding class. There are already protected localTracker > boolean variables that are true iff the value has been set. Adding an > is accessor for the property, e.g. is<Property>Set(), would resolve the > issue simply and fully. > > Does this seem a reasonable thing to do or am I missing something? > > If it is reasonable, even though I'm now out of date on the code base, > the ADBBindingTemplate.xsl is familiar ground from before. I could make > this extension if no one objects, else we'll probably patch this locally. > > Please advise. > > Thanks, > > Chuck > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
