Hi Noah,

The bad news is this looks to be a bug in how Castor hanndles the
schemna 'ref' attribute.

The good news is that if you change 

<xsd:element ref="person"/>

to 

<xsd:element name="person" type="personType"/>

It does work although the Authors class gets method
setPerson(java.lang.Object person).

Which isn't ideal, so I think there is also something wrong with using
'type' attribute handling in this scenario. :-(

Anyway I wrote a small test program to make sure its works in a
marhshal/unmarhsall case.

Seems to be OK if you don't mind the uggly cast! ;-)

import java.io.*;

public class Test
{
        public static void main(String[] args)
                throws Exception
        {
                // Marshal
                Class a = AuthorsDescriptor.class;
                Class b = PersonDescriptor.class;
                Authors authors = new Authors();
                Person person = new Person();
                person.setId("ID001");
                person.setName("Fred");
                authors.setPerson(person);
                StringWriter writer = new StringWriter();
                authors.marshal(writer);
                String xml = writer.toString();
                System.out.println(xml);

                // Unmarshal
                Authors authorsNew = (Authors) Authors.unmarshal(new
StringReader(xml));
                Person personNew = (Person) authors.getPerson();
                System.out.println(personNew.getName());
        }

}

Please can you raise a bug on the Castor JIRA site for this issue.

http://jira.codehaus.org/browse/CASTOR

Cheers,

Andy.


-----Original Message-----
From: Green, Noah [mailto:[EMAIL PROTECTED] 
Sent: 15 May 2005 22:36
To: [email protected]
Subject: [castor-user] [XML] Problems with importing no-namespace schema


Hi,
I'm working with a situation where my main schema has a target
namespace, and it imports another schema that does not have a namespace.
This example is taken directly from the O'Reilly book by Eric van der
Vlist called "XML Schema", section 10.9.   The main schema file is
called library.xsd and it has a namespace.  It is importing a schema
file called person.xsd that has no namespace.  When I try to generate
code, the process fails and says that library.xsd is not valid, because
the "person" element (imported from person.xsd) is not resolvable.  

I followed the syntax from the book exactly, and both files validate
fine in XML Spy.  Is this a bug or am I doing something wrong?

I have the two schema files, the binding file, and the Castor invocation
all below.  Note that I am trying to generate Java where each namespace
(including the no namespace) goes into a different package, but I hit
the same error even if I use no binding file and don't try to do this.
Both
type binding and element binding also lead to the error.  I am using the
generate imported schemas option.  Including rather than importing is
not an option for us; we are using the namespaces and the packages in
order to avoid naming collisions.

Any help here is greatly appreciated!!

Thanks!
-Noah

------------------------------------------------------------------------
------------------------------------------------------------------

Schema Files:

library.xsd:
<xsd:schema targetNamespace="http://dyomedea.com/ns/library";
                 elementFormDefault="qualified"
attributeFormDefault="unqualified"
                     xmlns:lib="http://dyomedea.com/ns/library";
                     xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
   <xsd:import schemaLocation="person.xsd"/>
   <xsd:element name="library">
      <xsd:complexType>
         <xsd:sequence>
            <xsd:element name="book" type="lib:bookType"/>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
   <xsd:complexType name="bookType">
      <xsd:sequence>
         <xsd:element name="title" type="xsd:string"/>
         <xsd:element name="authors">
            <xsd:complexType>
               <xsd:sequence>
                  <xsd:element ref="person"/>
               </xsd:sequence>
            </xsd:complexType>
         </xsd:element>
      </xsd:sequence>
      <xsd:attribute name="id" type="xsd:ID" use="required"/>
   </xsd:complexType>
</xsd:schema>

person.xsd:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
   <xsd:element name="person" type="personType"/>
   <xsd:complexType name="personType">
      <xsd:sequence>
         <xsd:element name="name" type="xsd:string"/>
      </xsd:sequence>
      <xsd:attribute name="id" type="xsd:ID" use="required"/>
   </xsd:complexType>
</xsd:schema>

------------------------------------------------------------------------
------------------------------------------------------------------

Binding file:

<binding defaultBindingType="type">
   <package>
      <name>test.lib</name>
      <namespace>http://dyomedea.com/ns/library</namespace>
   </package>

   <package>
      <name>test.person</name>
      <namespace />
   </package>
</binding>

------------------------------------------------------------------------
------------------------------------------------------------------

Castor invocation:

java org.exolab.castor.builder.SourceGenerator \
        -generateImportedSchemas -f -nomarshall -types j2 -I library.xsd
-dest /myjava -binding-file binding.xml

------------------------------------------------------------------------
------------------------------------------------------------------






------------------------------------------------------------------------
------
This message is intended only for the personal and confidential use of
the designated recipient(s) named above.  If you are not the intended
recipient of this message you are hereby notified that any review,
dissemination, distribution or copying of this message is strictly
prohibited.  This communication is for information purposes only and
should not be regarded as an offer to sell or as a solicitation of an
offer to buy any financial product, an official confirmation of any
transaction, or as an official statement of Lehman Brothers.  Email
transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such.  All information is
subject to change without notice.





The information in this message is confidential and may be legally privileged. 
It may not be disclosed to, or used by, anyone other than the addressee. If you 
receive this message in error, please advise us immediately.  Internet emails 
are not necessarily secure. CODA does not accept responsibility for changes to 
any email which occur after the email has been sent. Attachments to this email 
may contain software viruses, which could damage your systems. CODA has checked 
the attachments for viruses before sending, but you should virus-check them 
before opening.  

Reply via email to