Hi DM
It's arguable. I would say it's probably a small bug - and either way it
affects what I said to Pat so I've logged it in the JIRA. But having
said that the results look fairly minor to me.
The difference between your schema and Pat's is that you are using an
anonymous inner type (which is what I recommended to Pat as solution
#2).
So you have something like this:
<xs:element name="service-type">
<xs:complexType>
.
.
.
</xs:complexType>
</xs:element>
We are generating a class mapped to service-type. By default this would
be ServiceTypeDocument but you've chosen to override it with
ServiceTypeXml. Inside this interface there will be a) an inner
interface representing the anonymous complex type, and b) a
getter/setter pair for that anonymous complex type (actually there are
more than 1 getter/setter but let's keep it simple).
By default the name of that inner interface would be ServiceType (note -
this is an inner interface inside ServiceTypeDocument and so is not the
same as a global type generating a class called ServiceType which is
what Pat was seeing).
Also you would get a getter/setter pair called get/setServiceType().
Now you have overridden the name of the outer interface name to be
ServiceTypeXml. The question now becomes what should happen to the inner
interface name and the names of the getter/setter?
XmlBeans has taken the approach that the names of the getter/setter do
not change - they are still get/setServiceType(), but that the name of
the class generated for the anonymous type goes through the same
name-generation code as its parent. In this case therefore we try
ServiceTypeXml.
Now we run into a bit of code with a comment that says the following:
// Because we generate nested java interfaces, and nested
// interface names must not be the same as an ancestor, use up
// the ancestors
I wasn't aware of this limitation (and I haven't checked it), but if
true it looks like the Java Language requires that inner interface name
not be any part of the class name of its parent. ServiceTypeXml is
already there because of the parent and hence ServiceTypeXml2 is used.
Now this is bound to happen for any element containing an anonymous
complexType where the element name is overridden using a .xsdconfig
file. And furthermore the original name, ServiceType, is still
available. So that's why I consider it a small bug.
But having said that the getter/setter are still called
get/setServiceType() regardless. So the only thing that is affected is
an inner interface name.
Cheers,
Lawrence
> -----Original Message-----
> From: DM [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 15, 2006 1:41 AM
> To: [email protected]
> Subject: RE: generationg bean from schema with different name
>
> Hi,
>
> Thanks for your response Lawrence. I had a look at my own schema and
> .xsdconfig and the elements
> which I am generating alternative java names for do NOT have a global
type
> declared with a same
> name (as the element). In case you want to take a look I've attached
the
> schema, a sample instance
> document, and the .xsdconfig to this mail.
>
> One of the elements I'm aliasing is <service-type>. The only slightly
> unusual thing about this is
> that a <service-type> can contain other <service-type> elements.
However,
> I cannot find anything
> at all unusual about the other elements I'm aliasing, <monitored-
> property>.
>
> Best Wishes,
> DM
>
>
>
> ___________________________________________________________
> NEW Yahoo! Cars - sell your car and browse thousands of new and used
cars
> online! http://uk.cars.yahoo.com/
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
