Hi John,
Thanks for your mail, I will take the opportunity to clarify the
behavior of Castor since it seems to be a frequently experienced
problem:
When generating source for an element, Castor will check the
targetNamespace of that element and then it will associate a java
package to the corresponding class to be generated. In your case, the
sources for the embedded element 'detail' are in the default package and
not in the 'soap' package as you expect.
The reason is that in the following declaration
<xs:element name="detail" type="tns:detail" minOccurs="0" />
the targetNamespace associated to the element 'detail' is defined by the
XML schema spec:
"Element Declaration Schema Component
{target namespace} If form is present and its .actual value. is
qualified, or if form is absent and the .actual value. of
elementFormDefault on the <schema> ancestor is qualified, then the
.actual value. of the targetNamespace [attribute] of the parent <schema>
element information item, or .absent. if there is none, otherwise
.absent.. "
It means that there is no targetNamespace thus the package used will be
the default package specified at runtime.
You have several ways to fix that:
- define a form attribute locally on the element
- set the 'elementFormDefault' to 'qualified' on the <schema> element
- set the default package to be 'soap' in the SourceGenerator (-package)
Concerning the problem on the duplication of 'prefix' and 'suffix' in
the generated names, it should now be fixed in the CVS.
Hope that helps,
Arnaud
> -----Original Message-----
> From: Mazz Golf [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 28, 2003 10:28 PM
> To: [EMAIL PROTECTED]
> Subject: [castor-dev] bad generated java class names using namingXML
>
> I looked this up in BugZilla but couldn't find
> anything on it.
>
> I'm trying to run the SOAP schema
> (http://schemas.xmlsoap.org/soap/envelope/) through
> Castor v0.9.4.3. (This should be replicatable by
> anyone, hopefully, since I'm using the publicly
> available schema).
>
> I have a binding file to put suffixes/prefixes on some
> of the generated files because the SOAP schema uses
> the same name for elements and complex types (Header,
> Body, detail to name a few).
>
> My first binding file used <complexTypeName> - when it
> didn't work, I used <elementName>, but that didn't
> work either.
>
> The first binding file I used was:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <binding>
> <package>
> <name>soap</name>
>
> <namespace>http://schemas.xmlsoap.org/soap/envelope/</namespace>
> </package>
> <namingXML>
> <complexTypeName>
> <prefix>Prefix</prefix>
> <suffix>Suffix</suffix>
> </complexTypeName>
> </namingXML>
> </binding>
>
> I run the generator via Ant like this:
>
> <java
> classname="org.exolab.castor.builder.SourceGenerator"
> fork="false">
> <classpath refid="classpath" />
> <arg line="-i soap.xsd -dest ./src -verbose
> -binding-file ${binding.file}" />
> </java>
>
> But the generated code is bad and will not compile.
> Specifically, I am getting the following two classes
> generated in the anonymous, default Java package! They
> should have gone in the "soap" package which is what
> my binding file specified:
>
> Detail.java
> DetailDescriptor.java
>
> In the soap package, I do see a
> "PrefixdetailSuffix.java" and
> "PrefixdetailSuffixDescriptor.java". This is for the
> complex type "detail" found in the SOAP schema - I
> think the Detail.java is for the element "detail" (see
> the schema for the syntax).
>
> I then tried to use "elementName" instead:
>
> <namingXML>
> <elementName>
> <prefix>Prefix</prefix>
> <suffix>Suffix</suffix>
> </elementName>
> </namingXML>
>
> but when I generated the code I got similar (though
> not exact) results. Again I got two classes in the
> default Java package, not "soap" as expected - they
> were:
>
> PrefixdetailSuffix.java
> PrefixdetailSuffixDescriptor.java
>
> I think this is for the element "detail" from the
> schema. In the soap package, I got a bunch of
> generated files whose filenames looked correct. But
> the code is not compiling. There are a bunch of
> private member variables that are defined like this
> (from Envelope.java for an example):
>
> /**
> * Field _prefixprefixHeaderSuffixSuffix
> */
> private soap.PrefixPrefixHeaderSuffixSuffix
> _prefixprefixHeaderSuffixSuffix;
>
>
> Notice it is duplicating the prefix string and suffix
> string. There are no classes generated like that,
> however, there is a generated class
> "soap.PrefixHeaderSuffix".
>
> There are a bunch of variable declarations where these
> prefix and suffix strings are duplicated.
>
> In order to replicate this, I think all you need to do
> is get the publicly available SOAP schema from the URL
> mentioned above in this email and use the binding XML
> that I have above. Unless I'm doing something way off
> base (never count that possibility out ;-) I think
> this points to a problem in the Castor generation
> code.
>
> Can anyone verify this behavior on their systems?
>
> Thanks for any help.
>
> John Mazz
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
