Thanks Arnaud. It was my misunderstanding of which
namespace the elements inside of the Fault complex
type go in. I thought since the target namespace was
defined and Fault was in that namespace, that its
children also go in the target namespace.
Thanks for fixing the prefix/suffix duplication
problem.
--- Arnaud Blandin <[EMAIL PROTECTED]> wrote:
> 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.
>
=== message truncated ===
__________________________________
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
