Adam Chesney wrote:
Hi Dan,
I introduced "nullable" as well as the previous "nillable" property to
Type, so that we can use both the default Nillable value (as defined
in DefaultTypeMappingRegistry) and the nullability of a Java Type to
determine whether or not the property comes out as Nillable="true".
For example, a Date CAN be Null, so if your default value for Nillable
is false then Dates will come out as nillable="false" (or rather just
omitted). Equally, if your default value for Nillable is true, then
all Strings and Date's will come out as nillable="true" but all
primitives (int, long etc) will not because their nullable propery is
always false.
So, nullable is true for ALL Type's except primitives.
So I don't agree with your statement:
"dates are not nillable by default but Strings are"
Now, by default Nillable is true, so Dates AND Strings are nullable
and therefore come out as nillable="true". But if you change the
default Nillable property to false, then Dates and Strings will both
come out as nillable="false".
The problem was that before, the default (like Dates not being
Nillable) was hard coded whereas now, with the patch, the defaults are
configurable.
The default needs hardcoding. Dates need to be non nillable by default,
otherwise we break .NET 1.1 usage. In .NET dates are a value type and
can't be null. Thats why they need to have minOccurs=0.
I see the distinction you're trying to draw with nillable/nullable, but
I disagree. They're the same thing really. And different types need ot
have different nillable defaults. But then mapping files and annotations
can override this.
I need to look at your patch yet, but I would really like it to stay
this way for interoperability and ease of use reasons.
Thanks,
- Dan
So.... maybe the tests need changing :)
I will look at this properly tomorrow hopefully.
Cheers,
Adam.
----- Original Message ----- From: "Dan Diephouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 15, 2006 4:04 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL builder
Ok, it can wait until later. But all the tests do pass for me. I
suspect its that you're not using the Type.isNillable for the default
value. For instance, dates are not nillable by default, but Strings
are. I don't have time to look at it more today though as I'm
travelling.
Cheers,
- Dan
Adam Chesney wrote:
Hi Dan,
Unfortunately I'm off work due to illness, but I will try to take a
look at it either tomorrow or Friday.
However, I did have a weird problem with maven when doing a:
mvn install
I was getting messages about Java5 stuff being disabled even though
my system JDK was Java5, and the build failed with test errors
although they didn't seem to be related to the changes I had made,
so I figured one was related to the other.
Any ideas why that might have been?
Cheers,
Adam.
----- Original Message ----- From: "Dan Diephouse (JIRA)"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 15, 2006 2:34 PM
Subject: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL
builder
[ http://jira.codehaus.org/browse/XFIRE-295?page=all ]
Dan Diephouse updated XFIRE-295:
--------------------------------
Fix Version: 1.1-beta-1
Adam, this looks ok, but it seems that some of the tests don't
pass. Can you check them out? It seems like there are problems with
nillability and Dates. (See the BeanTest)
Also, if you could write a test or two to test the new
extensibility stuff that would be most appreciated.
optionally add xs:any & xs:anyAttribute to complex types produced
by Aegis WSDL builder
---------------------------------------------------------------------------------------
Key: XFIRE-295
URL: http://jira.codehaus.org/browse/XFIRE-295
Project: XFire
Type: New Feature
Components: Annotations, Aegis Module
Environment: all
Reporter: Adam J Chesney
Assignee: Dan Diephouse
Priority: Minor
Fix For: 1.1-beta-1
Attachments: JIRA295PlusAegisPatch.patch,
JIRA295PlusJava5Patch.patch
In order to future proof web service clients so that evolving
schemas do not
break existing clients, I would like to add some functionality to
the Aegis
WSDL building module.
The proposal is to optionally add:
<xs:any minOccurs="0" maxOccurs="unbounded"/>
and
<xs:anyAttribute/>
To complex types produced by the Aegis WSDL creation classes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
