See inline solution...
Adam Chesney wrote:
Hi Dan,
I like your changes. Just one problem that I have run into.
I call the DefaultTypeMappingRegistry constructor with createDefaults
= true because I want to create the default mappings. Now doing that
means that the typeCreator gets created in the constructor. So then
when I call setConfiguration (config) on the type mapping registry,
after construction, the configuration changes do NOT propagate to the
typeCreator and it's nextCreator. So, i can't actually change any of
the defaults!
Try this:
tr = new DefaultTypeMappingRegistry()
tr.setConfiguration(config);
tr.createDefaultMappingss();
So one solution is to allow the Configuration object to be passed into
the constructor of DefaultTypeMappingRegisty. Although that still
doesn't allow the user to call setConfiguration(config) after
construction and have the changes propagate to the typeCreator. That
would require adding setConfiguration to TypeCreator, calling it from
DefaultTypeMappingRegistry.setConfiguration(config) and then
implementing a chain to call setConfiguration(config) on the next
TypeCreator in AbstractTypeCreator I guess.
I can do a patch for either option if you would like?
Cheers,
Adam.
----- Original Message ----- From: "Dan Diephouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 21, 2006 7:05 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL builder
I committed my version of your patch to SVN. Let me know your
thoughts when you get a chance. I'm not tied to my code by any means.
:-)
- Dan
Dan Diephouse wrote:
Adam Chesney wrote:
Hi Dan,
comments inline...
Hi Adam,
I've been looking at this but still have problems with the
nillable stuff, but your example below breaks the semantics. You
stated in your other email:
We still need the 2 different properties in order to tell what is
ALLOWED to be Nillable (nullable) from what the user would LIKE to
be Nillable (nillable).
But in your snippet below, you're reversing those semantics.
setNullable(false) doesn't mean in that case that Date isn't
allowed to be Nillable, its just what the user would like. You
follow?
No... you said that Date's cannot be set to Nil="true" (even though
in Java they can be set to NULL) because of a limitation of .net.
So, I said that to make sure that we never output Nil="true" for
Date you can set Nullable to true as below. So, the
setNullable(true) is because Date's are not allowed to be Nilled,
it has nothing to do with the user's wishes.
Technically this is a user preference those. Dates can be nilled, we
just don't want to allow that by default if that makes more sense
:-) So they're allowed, its just bad for interop.
So... to reduce confusion we should probably change the nullable
property of Type.java to be called nillableAllowed.
Do you want me to do the refactoring and upload a new set of patches?
Nah, I have some other changes which I've integrated into your
patch. Specifically I created a Configuration object to pass around
settings (I need it for some other stuff later). Also, I removed the
minOccurs from Type because minOccurs can only be set on properties
of a bean.
On a related note, the patch is good and I appreciate it! I hope the
debate isn't giving the wrong impression :-). I think more than
anything I'm running into flaws in my design.
The real issue here is how do we know that a user hasn't
overridden the nillable property on the type. For instance, say I
create some custom type which I want to be nillable but set the
nillable default to false. The patch will overwrite that property
since there is no way to override it. Or the other way around - I
set a specific type's nillability to false but set the global
default to true. Once again it gets overridden.
I'm not sure there is a simple solution for this, but I'm up for
ideas...
You are right, if a user creates a new type, there is no way for
them to set the default value for Nillable to anything other than
the System wide default for Nillable. I also don't see an easy way
around this, but I also don't see it as a huge problem in the real
world. Surely, the presents of a global default for Nillable is
better than the not having it?
As I see it, in the real world the users probably sit in 2 camps:
1) Not bothered about highly constrained interfaces. In which case
they set the global default for Nillable and MinOccurs to true and
0 respectfully and maybe use the per property overrides to add
mandatory elements to their interface definition.
2) Highly constrained Interfaces are important. In which case they
set global defaults for Nillable and MinOccurs to false and 1
respectfully and then use per property overrides to declare
optional elements.
In either case, if they add their own user types, they probably
will not deviate from case 1) or 2) and therefore the fact that
they cannot set a default for their new Type that is different from
the global default is neither here nor there.
Adam.
Heres what I think might be a good solution:
- Only do setNillable(isDefaultNillable()) if we are creating a new
type (yours was overriding old types):
if (newType && !getTypeConfiguration().isDefaultNillable())
result.setNillable(false);
- Make sure that the default type mapping that is created in
DefaultTypeMappingRegistry respects
protected void register(TypeMapping tm, Class class1, QName name,
Type type)
{
if (!getTypeConfiguration().isDefaultNillable())
{
type.setNillable(false);
}
tm.register(class1, name, type);
}
This way we're only overriding the nillable property if we
explicitly want them all the be false. Which I think is the best way
to do things. Either you're going to want a mix of true/false or
have them all false by default. You'll never want to have them all
true by default.
I wrote an additional test or two and everything seems to check out
functionality wise.
Would that work for you?
- Dan
- Dan
Adam Chesney wrote:
Hi Dan,
Any idea when you will get a chance to integrate my updated patches?
http://jira.codehaus.org/browse/XFIRE-295?page=all
Then add:
public DateType()
{
setNullable(false);
}
to DateType.java
Cheers,
Adam.
----- Original Message ----- From: "Adam Chesney"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, March 16, 2006 4:21 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally
add xs:any & xs:anyAttribute to complex types produced by Aegis
WSDL builder
Hi Dan,
Ok well if dates can never be nillable then just override:
public booean isNullable()
{
return false;
}
in DateType.java, or alternatively call:
public DateType()
{
setNullable(false);
}
in the constructor.
This will mean that it will never come out as Nillable="true"
even if the default for Nillable is true. Which it is.
Repeat for any other types that cannot be Nilled.
We still need the 2 different properties in order to tell what
is ALLOWED to be Nillable (nullable) from what the user would
LIKE to be Nillable (nillable).
Cheers,
Adam.
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
