Adam Chesney wrote:
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.
Yeah you can :-)
<bean class="DefaultTypeMappingRegistry"
init-method="createDefaultMappings">
<property name="configuration" ../>
</bean
I have attached a patch that will propagate Configuration changes on
the DefaultTypeMappingRegistry to the TypeCreators.
FYI - the patch didn't come through.
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.
I think rather it just moved places :-). You'll notice that when we
create our default type mapping in DefaultTypeMappingRegistry, we're
setting the nillable property appropriately. Also, if we create new
Types (i.e. a new BeanType), we populate its nillable property based on
the setting in the Configuration (see DefaultTypeCreator).
So to recap, we *are* updating the default for nillable. You just need
to set isDefaultNillable beore you create your default type mappings and
before you create your 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
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
