OK Cool. I'm at TSS symposium right now, but I will see if I can get it
in sometime while I'm here. I need to catch up on emails and find a
better wireless connection first though :-)
- Dan
Adam Chesney wrote:
Hi Dan,
I've uploaded a patch to JIRA-295 that fixes this Nillable issue and
also fixes another issue that was breaking a bunch of tests (where
configuration on AbstractTypeCreator was null). The patch also
includes 2 new test cases (1 is the updated version of below that
discussed below).
If you still don't agree with my methodology then we can discuss other
ways of acheiving the same result, but it does now work in that you
can change all the defaults and those changes are reflected in the
default WSDL output.
Cheers,
Adam.
----- Original Message ----- From: "Dan Diephouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 22, 2006 2:36 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL builder
OK, I'll take a look and see what I can come up with. Maybe I am just
being stupid :-)
- Dan
Adam Chesney wrote:
Ok... have chganged the test to:
protected void setUp()
throws Exception
{
super.setUp();
DefaultTypeMappingRegistry reg = new
DefaultTypeMappingRegistry();
config = reg.getConfiguration();
XMLTypeCreator creator = new XMLTypeCreator();
creator.setConfiguration(reg.getConfiguration());
DefaultTypeCreator next = new DefaultTypeCreator();
next.setConfiguration(reg.getConfiguration());
creator.setNextCreator(next);
reg.createDefaultMappings();
tm = (CustomTypeMapping) reg.getDefaultTypeMapping();
tm.setTypeCreator(creator);
}
But the test still fails...
Adam
----- Original Message ----- From: "Dan Diephouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 22, 2006 2:25 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally add
xs:any & xs:anyAttribute to complex types produced by Aegis WSDL
builder
Adam Chesney wrote:
Ok... I'm not sure I follow.
I have added a new patch to JIRA295 called ConfigurationTest.patch
that is just a new Test Case.
It fails for Nillable. Have I done something wrong?
Yes :-). You are creating your default mappings before you set your
configuration. Try this:
DefaultTypeMappingRegistry reg = new DefaultTypeMappingRegistry();
//notice no "true"
config = reg.getConfiguration();
config.setDefaultNillable( false );
reg.createDefaultMappings();
// do tests now.
I suppose it would be good to have the configuration changes always
be reflected in the Type, but I didn't see a way to do that without
modifying *every* Type *every* time. Which I wasn't really
comfortable with. So now whenever we create a Type, it gets the
defaults that were present at that time. This should be ok though.
Regards,
- Dan
Cheers,
Adam.
----- Original Message ----- From: "Dan Diephouse"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, March 22, 2006 1:59 PM
Subject: Re: [xfire-dev] [jira] Updated: (XFIRE-295) optionally
add xs:any & xs:anyAttribute to complex types produced by Aegis
WSDL builder
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
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
