> -----Original Message-----
> From: Werner Guttmann [mailto:[email protected]]
> Sent: Wednesday, July 15, 2009 3:39 AM
> To: [email protected]
> Subject: Re: [castor-user] Confused about enabling "automatic"
conflict
> resolution
>
> Hi,
>
> KARR, DAVID (ATTCINW) wrote:
> > The current documentation seems to be ambiguous in specifying how
you
> > enable the "automatic" conflict resolution strategy. I've seen some
> > sections that say you set the
> > "org.exolab.castor.builder.automaticConflictResolution" property in
> > castorBuilder.properties to "true", and some to either "xpath" or
> > "type".
> The following is an excerpt of the castorbuilder.properties in SVN
> trunk:
>
> <quote>
> # Specifies whether automatic class name conflict resolution
> # should be used or not to resolve name conflicts during code
> # generation.
> # TODO: document in reference guide
> #
> # Possible values:
> # - false (default)
> # - true
> #
> # <pre>
> # org.exolab.castor.builder.automaticConflictResolution
> # </pre>
> #
> org.exolab.castor.builder.automaticConflictResolution=false
> </quote>
>
> Once you have enabled automatic conflict resolution, you face an
option
> to select the desired mode for conflict resolution, using
>
> SourceGenerator#setClassNameConflictResolver(String)
>
> Possible values are 'xpath' and 'type'.
>
> In case you select 'type' mode, there's another property to have a
look
> at:
For now, I'm not bothering to set this property, for a couple of
reasons. First, I'm willing to accept whatever conflict resolver it
wants to try ("xpath", by default). Second, I can't bloody figure out
how to set it. The documentation doesn't appear to say which property
it is or how to set it.
I also see that when I have this enabled, some of the conflicts are
resolved automatically, but some or not. I find two kinds of
occurrences in my schema. There are some that are actual conflicts,
where an element named "Foo" appears in a couple different places and
uses different "type" values. These appear to be automatically
resolved. However, there are some occurrences of "Bar" where the "type"
value is "Glork". The presence of these two identical elements, both
with the same type, also causes a conflict, and this is NOT
automatically resolved. It seems to me that this kind of conflict
should be easily resolvable, as there shouldn't be anything required to
do on the second and further occurrences, as the existing class could be
reused. Am I understanding this correctly?
If we had the ability to modify the schema, could we mitigate this with
defining top-level elements that are repeated and using "ref" to
reference them?
Also, I see that elements that only differ by case are conflicting, and
not resolving automatically. An element named "address" conflicts with
an "Address" element. I don't see any mention in the docs about this
issue. There is a "case-insensitive" option for enum value lookups (and
the doc doesn't explicitly say what the default value is), but not for
class names.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
