Hi Dan,
Well I am using Spring to configure my MappingRegistry so I can't call
createDefaultMappings() after setting the config. However, it turns out that
isn't the only issue.
I have attached a patch that will propagate Configuration changes on the
DefaultTypeMappingRegistry to the TypeCreators.
The patch also includes a new test case, ConfigurationTest that fails
because changes to the Configuration.setDefaultNillable(false) do not change
the default for Nillable. That is because in the base class BeanTypeInfo:
public boolean isNillable(QName name)
{
Type type = getType(name);
return type.isNillable();
}
So there is no way of updating the default for Nillable (unlike minOccurs),
as it just ends up being the value of Nillable as defined on the Type.
That is why my version used both the nullable property and the nillable
propery to determine Nillability. I think we should add a nillable property
to BeanTypeInfo and add a setDefaultNillable(boolean) method, just like for
minOccurs and then change isNillable to:
public boolean isNillable(QName name)
{
Type type = getType(name);
if (!type.isNillable()) return false;
return nillable;
}
What do you think?
Cheers,
Adam.
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
